-
Notifications
You must be signed in to change notification settings - Fork 179
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
204 No Content on HTTP/1.1 generates an empty chunk #41
Comments
This has been reported upstream as vinipsmaker/tufao#41
I've read the mentioned RFC2616 paragraph. Bug confirmed. I'll review the code over the week and merge it on all Tufão branches (with changes if needed). Thanks for the feedback. |
Thanks. My patch is against an old version (1.0.2), doesn't come with a unit test and as indicated in the commit message with some open questions I couldn't answer myself. E.g. how strictly do you want to enforce this rule? Should ::write() just return false and these things. I am looking forward for a proper fix. |
For this feature/patch, ain't a problem.
The tests cannot be done using headers, because the order is not guaranteed. Parsing the generated buffer if headers are present require a lot of implementation work. I'll leave this for later. Having said that, I can implement the tests, but I'll first focus on the documentation changes.
HTTP rules aren't very orthogonal and we end up with hacks like this. The only path I see to fix this bug is breaking orthogonality also on Tufão and make the body aware of the response status code. I don't want to enforce this rule to the user. Some behaviours of HTTP are unknown to Tufão and left to the user handle. For instance, RFC2616 document some HTTP verbs, but more were created by other protocols and Tufão doesn't know how to handle them, but it may be interesting for the user, then the task is left for the user to resolve. I'm heading to a compromise now, but my schedule is less busy now and I'll be able to review and merge the patch when I came back. Thanks for the responsive collaboration with the contribution. |
Fixed. @zecke, can you test the new version and confirm the fix? Then I'll release another stable version. |
I didn't verify it with REST Sharp (my downstream was using REST Sharp) but using curl and looking at the output in wireshark the last thing in the response is the \r\n and Content-Length is 0. |
The final Quoting section 4.4 of RFC 2616:
So, a single |
My code is doing:
This generates a 204 No Content, with Transfer-Encoding: chunked and includes and empty chunk '0\r\n\r\n'. But this is not valid according to the RFC2616:
10.2.5 204 No Content
...
The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields.
The Microsoft .NET HTTP Client is upset by the extra chunk being sent. The only work-around is to disable keep-alive by adding Connection: close to the request.
The text was updated successfully, but these errors were encountered: