-
Notifications
You must be signed in to change notification settings - Fork 2.5k
HTTP persistent connections should not be assumed for HTTP/1.0 #935
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
Comments
@dmiller-nmap FYI |
Looks good, please incorporate these changes whenever they are ready. |
A few questions:
|
To answer Dan's questions: Comparison Variations of "max=" HTTP 1.0 It is certainly possible to try request pipe-lining against HTTP/1.0 targets but IMHO it is detrimental to do so because: (1) The RFC says that it should not be done and (2) I have dived into this issue specifically because particular real-world HTTP/1.0 targets were not working at all with the current pipe-lining approach. |
Hello Dan, |
As a side note, the I do not see a reason to invest further into this unless somebody believes otherwise. |
Function
getPipelineMax
inhttp.lua
analyzes headers from a previously obtained HTTP response and attempts to guess how many HTTP requests can be batched together.In particular, it assumes that persistent connections are available unless header
Connection
is set toclose
.This is an oversimplification with respect to HTTP/1.0. See RFC 7230, section 6.3 for compliant behavior.
The following patch improves
getPipelineMax
by assuming that persistent connections are not available if the target response is HTTP/1.0 while missing the keep-alive connection option.Note that this patch has a dependency on proposal #934.
Please let me know if you have any questions or concerns. Otherwise I will commit the patch in a few weeks.
The text was updated successfully, but these errors were encountered: