Skip to content
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

Curl Post of a given size timeouts after curl ends up in an infinite loop #15688

Closed
alexissavin opened this issue Dec 5, 2024 · 5 comments
Closed
Assignees

Comments

@alexissavin
Copy link

alexissavin commented Dec 5, 2024

I did this

Create a file of the proper size (in my case the size that trigger the issue is 261680, it likely varies depending on the environment):
truncate -s 261680 test.tgz
Upload it to some http endpoint over SSL (nginx):
curl -v -X POST -Ffile=@test.tgz --url "https://domain.test/upload" --connect-timeout 30 --max-time 30;
The transfert timeout, using more verbose output ('-vvv'), we observe the following:

...
ff80: ................................................................
ffc0: ...........
ffcd: --------------------------eecMwy2lW5vukdsCCq1CPO--.
09:00:58.594998 [0-0] == Info: [SSL] ossl_bio_cf_in_read(len=5) -> -1, err=81
09:00:58.596477 [0-0] == Info: [SSL] cf_recv(len=102400) -> -1, 81
09:00:58.597919 [0-0] == Info: [READ] cr_mime_read(len=1), too small, return
09:00:58.599120 [0-0] == Info: [READ] cr_mime_read(len=1, total=261892, read=261891) -> 0, 0, 0
09:00:58.602436 [0-0] == Info: [READ] client_read(len=65536) -> 0, nread=0, eos=0
09:00:58.604165 [0-0] == Info: [SSL] ossl_bio_cf_in_read(len=5) -> -1, err=81
09:00:58.605379 [0-0] == Info: [SSL] cf_recv(len=102400) -> -1, 81
09:00:58.606428 [0-0] == Info: [READ] cr_mime_read(len=1), too small, return
09:00:58.607558 [0-0] == Info: [READ] cr_mime_read(len=1, total=261892, read=261891) -> 0, 0, 0
09:00:58.609084 [0-0] == Info: [READ] client_read(len=65536) -> 0, nread=0, eos=0
09:00:58.610537 [0-0] == Info: [SSL] ossl_bio_cf_in_read(len=5) -> -1, err=81
....

I highly suspect a relation with some code from commit c90a3f1:

Curl_mime_read() may go into an infinite loop when called with buffer lengths <= 4. Some encoders, like base64, are not prepared for that.

I expected the following

Transfert should complete normally (as it did in the past using curl 8.6.0 or 8.8.0).
Issue seems occurring in curl >= 8.10.0.

curl/libcurl version

# curl --version
curl 8.10.1 (amd64-portbld-freebsd14.1) libcurl/8.10.1 OpenSSL/3.0.15 zlib/1.3.1 libpsl/0.21.5 libssh/0.11.1/openssl/zlib nghttp2/1.64.0
Release-Date: 2024-09-18
Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: alt-svc AsynchDNS HSTS HTTP2 HTTPS-proxy IPv6 Largefile libz NTLM PSL SSL threadsafe TLS-SRP UnixSockets

operating system

FreeBSD 14.2-STABLE

@alexissavin
Copy link
Author

@icing since you authored #c90a3f1 maybe you will see clearer into this ?

icing added a commit to icing/curl that referenced this issue Dec 5, 2024
The base64 mime encoder stalls when it cannot encode a full
3 byte input set into the read buffer. The workaround for this
limitation was incomplete and could lead to stalled transfers
when the last chunk to upload was smaller than 4 bytes.

Use a tmp buffer on small reads to allow mime encoders more
space to put their things.

Add test case reproducing the issue and fix.

refs curl#15688
@icing
Copy link
Contributor

icing commented Dec 5, 2024

Thanks for your precise report. I was able to reproduce the problem in a test case and made a fix in #15691. Hope this works for you as well.

@bagder bagder closed this as completed in ce949ba Dec 5, 2024
@alexissavin
Copy link
Author

Thanks for the prompt feedback and fix.
Any idea when this could be officially released ?

@icing
Copy link
Contributor

icing commented Dec 5, 2024

It will be part of curl 8.11.1 on December 11th.

@alexissavin
Copy link
Author

Excellent, many thanks

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

No branches or pull requests

2 participants