websockets-rs / websockets-rs/rust-websocket
Upgrade Via HyperRequest Sends Bogus Data At End of Connection
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 1.6k
- Forks
- 225
- PR merge metrics
- No merged PRs in 30d
Description
The example snippet to upgrade a HyperRequest to a websocket client works fine. I'm basing a server on it.
Server::http("0.0.0.0:80").unwrap().handle(move |req: Request, res: Response| {
match HyperRequest(req).into_ws() {
Ok(upgrade) => {
...
But there is a problem. At the end of my connection and I return from the handler, a client receives some "bogus" data. This data is due to the fact that the res in the handler is unused. According to the hyper doc
(https://docs.rs/hyper/0.10.6/hyper/server/response/struct.Response.html):
There is a Drop implementation for Response that will automatically write the head and flush the
body, if the handler has not already done so, so that the server doesn't accidentally leave
dangling requests.
My work-around is to flush the stream and wait a bit, hoping that the client has closed the connection upon receiving the Close message.
It would be nice if there was an accept/reject function that writes to res. In this way, res is marked as processed and won't get flushed.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the example using HyperRequest(req).into_ws() and read hyper's Response documentation, especially its Drop behavior. Trace how the unused res is finalized and verify the websocket client no longer receives bogus data at connection end; the proposed accept/reject handling should mark the response as processed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100