Repository navigation
gh-70765: avoid waiting for HTTP headers when parsing HTTP/0.9 requests - #139514
picnixz merged 3 commits into
Conversation
Sorry, something went wrong.
serhiy-storchaka
left a comment
There was a problem hiding this comment.
LGTM. 👍
Sorry, something went wrong.
|
Thanks @picnixz for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13, 3.14. |
Sorry, something went wrong.
…requests (pythonGH-139514) (cherry picked from commit 13dc2fd) Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
|
Sorry, @picnixz, I could not cleanly backport this to 3.13 due to a conflict. cherry_picker 13dc2fde8cec1e8aad04c7635b3da4ff3e3dcb00 3.13 |
Sorry, something went wrong.
|
GH-139600 is a backport of this pull request to the 3.14 branch. |
Sorry, something went wrong.
…TP/0.9 requests (pythonGH-139514) (cherry picked from commit 13dc2fd) Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
|
GH-139602 is a backport of this pull request to the 3.13 branch. |
Sorry, something went wrong.
|
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. |
Sorry, something went wrong.
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.
…requests (pythonGH-139514) (cherry picked from commit 13dc2fd) (cherry picked from commit 1fe89d3) Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
…TP/0.9 requests (pythonGH-139514) (cherry picked from commit 13dc2fd) (cherry picked from commit 1fe89d3) Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
…TP/0.9 requests (pythonGH-139514) (cherry picked from commit 13dc2fd) (cherry picked from commit 1fe89d3) Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
…TP/0.9 requests (pythonGH-139514) (cherry picked from commit 13dc2fd) (cherry picked from commit 1fe89d3) Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
…TP/0.9 requests (pythonGH-139514) (cherry picked from commit 13dc2fd) (cherry picked from commit 1fe89d3) Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
|
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.) |
Sorry, something went wrong.
…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.
@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.