-
Notifications
You must be signed in to change notification settings - Fork 552
HTTP: update 1xx status handling #2048
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
base: master
Are you sure you want to change the base?
Conversation
Check Squid behaviour conforms to RFC 9110 and RFC 9112 requirements. Update code documentation to reference latest RFCs. Move 'can handle' logic to the HTTP Server object, most of the requirements rely on server state, not HTTP request message.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I will come back to this PR (that does not even build right now) when the backlog is empty, but I left a few comments to facilitate progress.
src/http.cc
Outdated
// A server that receives an Upgrade header field in an | ||
// HTTP/1.0 request MUST ignore that Upgrade field. | ||
if (request->http_ver <= Http::ProtocolVersion(1,0)) | ||
return "HTTP/1.0 does not suport Upgrade header field"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would Squid ever send a request that violates this MUST? If this check is really needed, it should go into request sending code, not response receiving code. If our sending code is correct, and we want to police versions in this case, then we can assert that the version is OK here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK today an ICAP/eCAP service can add Upgrade
values which are blindly copied for delivery.
In future we may also want to proactively offer upgrades to better protocols (eg HTTPS, HTTP/2, etc).
This being a MUST requirement, IMO its worth checking to ensure we do not accidentally violate it.
Co-authored-by: Alex Rousskov <[email protected]>
Check Squid behaviour conforms to RFC 9110 and RFC 9112
requirements.
Update code documentation to reference latest RFCs.
Move 'can handle' logic to the HTTP Server object. Most of the
requirements are checking server state, not HTTP request
message.
Add performance optimization to 101 Switching Protocols logic.
Avoids memory setup for handling the Upgrade list header
unless the header actually exists and needs processing.
Do not send 1xx status when the client connection transport is
HTTP/1.0 or HTTP/0.9 unless client sent Expect:100-continue.