Consume chunked request fully#619
Conversation
| else | ||
| { | ||
| // Post request headers | ||
| throw new NotImplementedException("INVALID REQUEST FORMAT"); |
There was a problem hiding this comment.
I don't think NotImplementedException is the right exception to throw here. InvalidOperationException seems more appropriate.
There was a problem hiding this comment.
This though could be valid http (trailing headers)
There was a problem hiding this comment.
Oh, if you're not going to process incoming trailer headers you should drain them and file a bug to deal with them later.
|
Resolved issues. @CesarBS question on whether to go |
| } | ||
| else if (ch1 == '\r' && ch2 == '\n') | ||
| { | ||
| input.ConsumingComplete(scan, scan); |
There was a problem hiding this comment.
ConsumingComplete should be called in a finally block. We're not consistent about doing that in this class (I'll fix that soon), but that is the recommended calling pattern.
There was a problem hiding this comment.
I think the latest commit fixes this - but I can't compile it due to
Unable to resolve Microsoft.DotNet.CoreHost (>= 0.0.1-beta-00001) for DNXCore,Version=v5.0
|
|
||
| private static void ThrowInvalidFormat() | ||
| { | ||
| throw new InvalidOperationException("INVALID REQUEST FORMAT"); |
There was a problem hiding this comment.
Can you switch to lowercase? Not sure why it was all uppercase to begin with, but since you're changing this it would be nice to be consistent (and better looking 😄) with the rest.
There was a problem hiding this comment.
All caps is LogLevel.CRITICAL! ;-)
|
Capturing comment hidden in outdated diff
|
bc3cfff to
6e616c9
Compare
|
Now parses the trailing headers |
3347162 to
7b029a2
Compare
|
Test for parsing headers |
f5731fd to
4d2a886
Compare
|
|
||
| if (requestsReceived < requestCount) | ||
| { | ||
| Assert.Equal(new string('a', requestsReceived), request.Headers["X-Trailer-Header"]); |
There was a problem hiding this comment.
Cool. Now I'm interested to see if this feature gets used even once in the wild. You should find a way to take advantage of this in one of your games 😉
There was a problem hiding this comment.
Might be a stretch even for me 😉
Linked to discussion from "Web Hypertext Application Technology Working Group" (whatwg) in https://github.com/aspnet/KestrelHttpServer/issues/622 - think it needs a custom client rather than browser.
|
Do you see these errors? If not, I can investigate tomorrow. |
|
On and off - get it with the other closing tests also (e.g. Http10ContentLength). Normally seems to happen if I run the tests repeatedly rather than in clean Can wrap in a Couldn't get to the bottom of it though :( |
|
However... Kestrel should probably also abort the connection for those tests; which cause the issue also. (As they will have poisoned the connection) |
f7baf73 to
889e6ab
Compare
|
K should now be returning 400 and chopping the connection; not getting the earlier exception either - might have been overflow junk into the next request causing the connection to chop? |
|
Hmm, not perfect; if user code caught the exception and threw it away it would still go wrong... |
|
Should still close connection even if user code handles it now. |
|
@halter73 that error is caused by Issues resolved. |
a7c27d0 to
b82a251
Compare
|
Rebased, better bad request handling for headers and invalid content lengths |
|
Re-rebased for newest; resolving errors for newer tests. |
b82a251 to
766803c
Compare
|
I'm getting an failure in the cctor for MessageBody.ForChunkedEncoding of Invalid Program exception on full framework. If I move |
|
AppVeyor: |
Chunked requests have an extra
\r\nat endResolves #617
@Tratcher is this correct?
/cc @CesarBS @halter73
Please note changes in tests