Add default (non-blank message) on GET

[craigloewen-msft]

I'm trying to deploy my server to the cloud with this, but it isn't responding to any HTTP requests and so the connection is getting closed automatically.

Expected Behaviour

Like a regular web socket, if you get it, you get a reply back:

craig@CPC-crloe-5BDW5:~$ curl -v http://localhost:8080
* Host localhost:8080 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:8080...
* Connected to localhost (::1) port 8080
> GET / HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/8.5.0
> Accept: */*
>
< HTTP/1.1 426 Upgrade Required
< Content-Length: 16
< Content-Type: text/plain
< Date: Wed, 18 Dec 2024 23:18:57 GMT
< Connection: keep-alive
< Keep-Alive: timeout=5
<
* Connection #0 to host localhost left intact
Upgrade Required

Actual Behaviour

You get an empty reply back (Breaking the app)

craig@CPC-crloe-5BDW5:~$ curl -v localhost:8081
* Host localhost:8081 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:8081...
* Connected to localhost (::1) port 8081
> GET / HTTP/1.1
> Host: localhost:8081
> User-Agent: curl/8.5.0
> Accept: */*
>
* Empty reply from server
* Closing connection
curl: (52) Empty reply from server

Recommended improvement

Is it possible to make it reply something non-empty on the regular GET? This would make it possible to use it with Azure Web App Service.

Thanks @NoahShomette !!

[NoahShomette]

Are you sending an http request through the client, from outside the client, or is it just crashing as soon as a connection is made? Server or client crashing?

[NoahShomette]

I'm sorry I see you are using curl, disregard that question haha.

I did a bit of surface level digging and I wanted to share info with you that you might understand better (I'm not the greatest with networking lol). The underlying crate used here for the connection is tungstenite-rs. Based on this issue it doesn't seem like they support http requests through the connection. Some of what they discuss in that issue might be helpful to you as well as if you shared your use case with them for additional support for that feature.

I'm not entirely sure responding to an http request would be resolvable/possible on my end as by the time we get the message its already gone through the connection and we are just getting the payload and not any other info.

Do you get an error message on the server when it crashes? It might be possible to send it a correctly formatted ws request instead of an http one but thats a guess and I'm not sure how that would work.

[craigloewen-msft]

Hmm I'll close this out then (I too am no networking expert). I think I can finangle this to get it working through a server some other way. Thanks for taking a look at this though! :)