Skip to content

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

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

yadij
Copy link
Contributor

@yadij yadij commented Apr 3, 2025

  • 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.

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.
Copy link
Contributor

@rousskov rousskov left a 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";
Copy link
Contributor

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.

Copy link
Contributor Author

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.

@yadij yadij requested a review from rousskov April 5, 2025 10:54
@yadij yadij added the S-waiting-for-reviewer ready for review: Set this when requesting a (re)review using GitHub PR Reviewers box label Apr 5, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-for-reviewer ready for review: Set this when requesting a (re)review using GitHub PR Reviewers box
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants