Skip to content

Preserve 100-continue wait through 102 and 103 responses - #211

Open
AryanRG wants to merge 3 commits into
python-hyper:masterfrom
AryanRG:fix/early-hints-100-continue
Open

AryanRG wants to merge 3 commits into
python-hyper:masterfrom
AryanRG:fix/early-hints-100-continue

Conversation

@AryanRG

@AryanRG AryanRG commented Oct 17, 2026 •

Copy link
Copy Markdown

A request with Expect: 100-continue can receive 102 Processing or 103 Early Hints before the server asks for its body. Those interim responses do not tell the client to send content, but h11 currently clears the wait flag for every informational response. A server following the documented wait guard can then omit 100 Continue and wait for a body that the client has not sent.

Preserve the outstanding wait through non-100 informational responses. Keep the existing clearing behavior for 100 Continue, 101 Switching Protocols, final responses, and client body transmission. Update the API explanation and add regression cases for repeated 102/103 responses and subsequent flag clearing. The release note is named 211.bugfix.rst for this PR.

Validation:

  • New 102 and 103 cases failed on the pristine base; both pass with this change.
  • Full local suite: 80 passed on Python 3.9, 3.12, and 3.13.
  • Black, isort, mypy, and diff checks passed.
  • Local overall coverage remains 98.2%, the same as baseline; this does not establish the contributor guide target of 100%. Hosted CI and the remaining interpreter matrix are not yet run.

AI assistance was used to investigate, implement, test, and review this change.

@AryanRG
AryanRG marked this pull request as ready for review October 17, 2026 03:51

@Muguett-DBY Muguett-DBY left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I checked the state transitions on base 62c5068 and this head using a pair of h11 connections. For statuses 102–199, the base clears the wait flag and the proposed change preserves it; a subsequent 100 clears it on both sides. Final responses (200, 400 and 417), a client sending its body early, repeated informational responses, and a second request on the same connection also behaved as expected. I checked a protocol upgrade after 100 and the request body as well.

One small documentation suggestion: could the flow-control paragraph mention that a client may send the body without waiting indefinitely for a response? RFC 9110 §10.1.1 allows that, and the implementation already clears the flag when body data arrives.

The checks ran on Windows with Python 3.12.14 and 3.15.1, passing h11-generated bytes directly between the two connections. They did not use sockets or run the full project suite. I used Codex to help prepare the checks and review.

@AryanRG

AryanRG commented Oct 27, 2026

Copy link
Copy Markdown
Author

Thanks, added that clarification to the flow-control section.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants