Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unread body data from prior request is interpreted as second request #1297

Closed
jethrogb opened this issue Aug 25, 2017 · 4 comments
Closed

Unread body data from prior request is interpreted as second request #1297

jethrogb opened this issue Aug 25, 2017 · 4 comments

Comments

@jethrogb
Copy link
Contributor

In hyper 0.10 I have this simple server:

extern crate hyper;
use hyper::server::{Server, Request, Response};

fn hello(req: Request, res: Response) {
    res.send(format!("{:?}",req.method).as_bytes()).unwrap();
}

fn main() {
    Server::http("0.0.0.0:12346").unwrap().handle(hello).unwrap();
}

When sending this request stream:

POST / HTTP/1.1
Host: localhost:12346
User-Agent: curl/7.47.0
Accept: */*
Content-Length: 4
Content-Type: application/x-www-form-urlencoded

bodyPOST / HTTP/1.1
Host: localhost:12346
User-Agent: curl/7.47.0
Accept: */*
Content-Length: 4
Content-Type: application/x-www-form-urlencoded

body

The second response body is Extension("bodyPOST"). The unread body of the first request got read as part of the second request. You can generate these request like so:

curl -v -d body http://localhost:12346 http://localhost:12346
@seanmonstar
Copy link
Member

This is #540, with the root being #309.

@jethrogb
Copy link
Contributor Author

#309 is closed but the bug still exists?

@seanmonstar
Copy link
Member

It's closed as fixed in >=0.11.

@seanmonstar
Copy link
Member

There isn't really a way to fix this without breaking compatibility.

The problem is that the Request can be deconstructed, and the HttpReader is a public enum, which is what keeps track of whether the body has been read or not. So there isn't anywhere to add a field, or add a Drop impl, or anything, that could signal that the socket shouldn't be read from for a new request.

Given the effort to try to find some way to fix this without breaking 0.10.x users, and that 0.10.x isn't receiving any more development, I'm going to close this as a wontfix.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants