-
-
Notifications
You must be signed in to change notification settings - Fork 6.4k
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
HTTP/2 upload too large request does not immediately end #15316
Comments
Thanks for the report. Could you generate a trace adding |
upload-endless-wait.log |
Thanks. The uncommon thing here is that the server does not RST the stream, as it clearly has no intention of reading any more data from curl. You seem to hide its identity, but maybe you can reveal what http/2 server that is? May help us in future trouble shooting. That curl does not abort the transfer upon getting the 413 is a bug. I will work on a fix. |
When a server signals EOS from its side and the curl upload is unfinished and the server has not given a positive HTTP status response, auto RST the stream to signal that the upload is incomplete and that the whole transfer can be stopped. refs curl#15316, where the server responds with 413 on an upload but does not RST the stream from its side, as httpd and others do.
Could you try #15325 in your setup to see if this works there too? I can only simulate the situations partially with our test servers as they reset streams in such situations. |
There seems to be some routing component I don't have control over. When querying an nginx or apache directly it behaves differently. With the patch curl exits quickly and with the normal 0 exit code. End logging now looks like this:
|
I did this
Create a request where the server is going to reply
HTTP/2 413
. Using curl cli to make the request:I expected the following
curl to end quickly without an error code, but instead curl waits for the server as if it wants to upload the full data or another request. The server closes the connection (for me 5 minutes) and then curl ends with error 18.
Same output but from curl 7.81.0 (reported 8.6.1 should have been good too)
curl/libcurl version
curl 8.10.1 (x86_64-pc-linux-gnu) libcurl/8.10.1 OpenSSL/3.0.2 zlib/1.2.11 zstd/1.4.8 libpsl/0.21.0 nghttp2/1.43.0 OpenLDAP/2.5.18
Release-Date: 2024-09-18
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: alt-svc AsynchDNS HSTS HTTP2 HTTPS-proxy IPv6 Largefile libz NTLM PSL SSL threadsafe TLS-SRP UnixSockets zstd
operating system
Linux ip-192-168-10-106 6.8.0-1015-aws #16~22.04.1-Ubuntu SMP Mon Aug 19 19:38:17 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux
The text was updated successfully, but these errors were encountered: