Skip to content

Conversation

@picnixz
Copy link
Member

@picnixzpicnixz commented Oct 2, 2025

@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_request is never called because of that.

@picnixzpicnixz changed the title gh-139492: fix default handling of HTTP/0.9 requestsgh-70765: fix default handling of HTTP/0.9 requestsOct 2, 2025
@picnixzpicnixzforce-pushed the fix/http/legacy-handler-139492 branch from 74a818a to 048ee83CompareOctober 2, 2025 16:15
@picnixzpicnixz requested a review from vadmiumOctober 2, 2025 16:15
@serhiy-storchakaserhiy-storchaka added needs backport to 3.13 bugs and security fixes needs backport to 3.14 bugs and security fixes labels Oct 5, 2025
Copy link
Member

@serhiy-storchakaserhiy-storchaka left a comment

Choose a reason for hiding this comment

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

LGTM. 👍

@picnixzpicnixz changed the title gh-70765: fix default handling of HTTP/0.9 requestsgh-70765: Avoid waiting for HTTP headers when parsing HTTP/0.9 requestsOct 5, 2025
@picnixzpicnixz changed the title gh-70765: Avoid waiting for HTTP headers when parsing HTTP/0.9 requestsgh-70765: avoid waiting for HTTP headers when parsing HTTP/0.9 requestsOct 5, 2025
@picnixzpicnixz enabled auto-merge (squash) October 5, 2025 11:55
@picnixzpicnixz merged commit 13dc2fd into python:mainOct 5, 2025
89 of 91 checks passed
@miss-islington-app
Copy link

Thanks @picnixz for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14.
🐍🍒⛏🤖 I'm not a witch! I'm not a witch!

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]>
@miss-islington-app
Copy link

Sorry, @picnixz, I could not cleanly backport this to 3.13 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker 13dc2fde8cec1e8aad04c7635b3da4ff3e3dcb00 3.13 

@bedevere-app
Copy link

GH-139600 is a backport of this pull request to the 3.14 branch.

@bedevere-appbedevere-appbot removed the needs backport to 3.14 bugs and security fixes label Oct 5, 2025
@picnixzpicnixz deleted the fix/http/legacy-handler-139492 branch October 5, 2025 12:11
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]>
@bedevere-app
Copy link

GH-139602 is a backport of this pull request to the 3.13 branch.

@bedevere-appbedevere-appbot removed the needs backport to 3.13 bugs and security fixes label Oct 5, 2025
@picnixz
Copy link
MemberAuthor

picnixz commented Oct 5, 2025

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]>
@vadmium
Copy link
Member

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
… requests (GH-139514) (#139602) (cherry picked from commit 13dc2fd) (cherry picked from commit 1fe89d3)
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 freeto 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.

3 participants

@picnixz@vadmium@serhiy-storchaka