fix(server): Drain requests on drop. #310
Conversation
If a client sent an illegal request (like a GET request with a message body), or if there was a legal request with a body but the Handler didn't read all of it, the remaining bytes would be left in the stream. The next request to come from the same client would error, as the server would confuse the remaining bytes, and think the request was malformed. Fixes #197 Fixes #309
seanmonstar
force-pushed
the
server-request-drop
branch
from
5f43285
to
3d0f423
Compare
|
@reem fixed the draining logic. I just use Switching to new io will just require changing NullWriter to Sink. The EOF logic is handled inside copy, so nothing to screw up. |
|
Looks great. |
fix(server): Drain requests on drop.
|
Actually, this is a horrible idea security-wise, I think. I may start reading a request body, see it's super long, and quit. I do not expect hyper to silently read the other 40 GB of that request. |
|
Oh dang, good catch. I'll look at nodejs for inspiration. On Sat, Feb 14, 2015, 3:12 PM Jonathan Reem notifications@github.com
|
If a client sent an illegal request (like a GET request with a message
body), or if there was a legal request with a body but the Handler
didn't read all of it, the remaining bytes would be left in the stream.
The next request to come from the same client would error, as the server
would confuse the remaining bytes, and think the request was malformed.
Fixes #197
Fixes #309