-
Notifications
You must be signed in to change notification settings - Fork 567
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
Reset connection after HEAD? #258
Comments
Can't we just throw on |
If there's any data that we don't expect, we can also reset the connection at that point. |
That's a valid header for a HEAD response?
Hard to determine. What if the extra data (i.e. HEAD body) contains data that looks like a proper response? |
Ah, you're right.
Then resetting the connection would make sense, but indeed, it would be a significant performance drop. But there are lots of edge cases like that so I wouldn't go for this. IMO, if it looks like a proper response, it should be parsed, and if the |
E.g. GET receives |
Yea, I guess it's not really solvable. |
We could reset connection after content-length: 0 as well 😄 |
So it turns out that Node actually does reset connection after HEAD. See, nodejs/node#12396. I think it might make sense for us to do so as well. Thoughts? @mcollina @szmarczak |
+1 |
Continuing from nodejs/node#34350.
Some servers send a body with HEAD requests which is kind of un-parsable. There is however one way to be resilient against it. Always reset the connection after receiving the message headers for a HEAD request.
This would make things significantly slower though but much more resilient. How important are HEAD requests?
Should we just ignore this unfortunate case and hope that the target server behaves properly?
Opt-in/Opt-out option?
The text was updated successfully, but these errors were encountered: