gh-70765: avoid waiting for HTTP headers when parsing HTTP/0.9 requests #139514
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
picnixz
changed the title
picnixz
force-pushed
the
fix/http/legacy-handler-139492
branch
from
74a818a to
048ee83
Compare
serhiy-storchaka
added
needs backport to 3.13
picnixz
changed the title
picnixz
changed the title
|
Thanks @picnixz for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14. |
miss-islington
pushed a commit
to miss-islington/cpython
that referenced
this pull request
Oct 5, 2025
…requests (pythonGH-139514) (cherry picked from commit 13dc2fd) Co-authored-by: Bénédikt Tran <[email protected]>
|
Sorry, @picnixz, I could not cleanly backport this to |
|
GH-139600 is a backport of this pull request to the 3.14 branch. |
picnixz
added a commit
to picnixz/cpython
that referenced
this pull request
Oct 5, 2025
…TP/0.9 requests (pythonGH-139514) (cherry picked from commit 13dc2fd) Co-authored-by: Bénédikt Tran <[email protected]>
|
GH-139602 is a backport of this pull request to the 3.13 branch. |
|
Ok, so I think something happens here where the connection is still closed on macOS. On Linux or in the CI I didn't have any issue but it appears that we could have a reset by peer error on macOS: https://github.com/python/cpython/actions/runs/18260872622/job/51988587155?pr=139607. I don't know why, but I guess it's something I didn't think of. I'll move to my dev session again to fix this. |
picnixz
added a commit
that referenced
this pull request
Oct 5, 2025
Fix a flaky test introduced in 13dc2fd. After a single HTTP/0.9 request, both client and server are expected to close the connection on their side. In particular, if a client sends two requests with the same connection, only the first one should be handled. In the tests, it might happen that checking for the second request to be ignored did not take into account that the server may have already closed the connection. This flaky behavior was first observed on macOS CI workers but could not be reproduced locally on a Linux machine.
picnixz
added a commit
to miss-islington/cpython
that referenced
this pull request
Oct 5, 2025
…requests (pythonGH-139514) (cherry picked from commit 13dc2fd) (cherry picked from commit 1fe89d3) Co-authored-by: Bénédikt Tran <[email protected]>
picnixz
added a commit
to picnixz/cpython
that referenced
this pull request
Oct 5, 2025
…TP/0.9 requests (pythonGH-139514) (cherry picked from commit 13dc2fd) (cherry picked from commit 1fe89d3) Co-authored-by: Bénédikt Tran <[email protected]>
picnixz
added a commit
to miss-islington/cpython
that referenced
this pull request
Oct 5, 2025
…TP/0.9 requests (pythonGH-139514) (cherry picked from commit 13dc2fd) (cherry picked from commit 1fe89d3) Co-authored-by: Bénédikt Tran <[email protected]>
picnixz
added a commit
to miss-islington/cpython
that referenced
this pull request
Oct 5, 2025
…TP/0.9 requests (pythonGH-139514) (cherry picked from commit 13dc2fd) (cherry picked from commit 1fe89d3) Co-authored-by: Bénédikt Tran <[email protected]>
picnixz
added a commit
to picnixz/cpython
that referenced
this pull request
Oct 5, 2025
…TP/0.9 requests (pythonGH-139514) (cherry picked from commit 13dc2fd) (cherry picked from commit 1fe89d3) Co-authored-by: Bénédikt Tran <[email protected]>
|
Getting ECONNRESET when sending to a TCP socket when the remote end has shut down is probably a normal behaviour. The remote end might reply with a TCP reset packet. I don't have experience with Mac OS or BSD but perhaps it could receive that reset packet synchronously and reports it as an error from the send call. (On the other hand, I think Linux receives it asynchronously after send to localhost has returned.) |
danigm
pushed a commit
to openSUSE-Python/cpython
that referenced
this pull request
Oct 7, 2025
danigm
pushed a commit
to openSUSE-Python/cpython
that referenced
this pull request
Oct 7, 2025
…on#139610) Fix a flaky test introduced in 13dc2fd. After a single HTTP/0.9 request, both client and server are expected to close the connection on their side. In particular, if a client sends two requests with the same connection, only the first one should be handled. In the tests, it might happen that checking for the second request to be ignored did not take into account that the server may have already closed the connection. This flaky behavior was first observed on macOS CI workers but could not be reproduced locally on a Linux machine.
picnixz
added a commit
that referenced
this pull request
Oct 8, 2025
picnixz
added a commit
that referenced
this pull request
Oct 8, 2025
… requests (GH-139514) (#139600) (cherry picked from commit 13dc2fd) (cherry picked from commit 1fe89d3) Co-authored-by: Bénédikt Tran <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
@Carmina16 with this patch, the handler should be correct. The tests did not catch this regression because we use a shortcut for sending requests and
parse_requestis never called because of that.