[Regression] libcurl does not finish CURLOPT_UPLOAD request after a connection lost without data tranfer

[ligurio]

I did this

There was an issue in Tarantool ¹ due to regression in libcurl (#11769), it was reported on 23 Aug, 2023. Issue was fixed in upstream on 4 Sept, 2023 and fix was confirmed by our tests for Tarantool. Unfortunately, this fix was ruined by refactoring made in commit d7b6ce6 ("lib: replace readwrite with write_resp") [3] on 1 Dec 2023, and now it is reproduced again.

• Reproducer for Tarantool is described in ¹
• Reproducer for libcurl is described in libcurl does not finish CURLOPT_UPLOAD request after a connection lost without data tranfer #11769, I'm not sure, it is worth to duplicate it here

I expected the following

• Apply reverted fix for libcurl does not finish CURLOPT_UPLOAD request after a connection lost without data tranfer #11769
• Convert reproducer in libcurl does not finish CURLOPT_UPLOAD request after a connection lost without data tranfer #11769 to a test to avoid regression in a future.

curl/libcurl version

8.6.0+

operating system

uname -a: Linux pony 6.5.0-26-generic #26~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Mar 12 10:22:43 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

Ubuntu 22.04.4 LTS

Footnotes

1. https://github.com/tarantool/tarantool/issues/9086 ↩ ↩²

[icing]

I tried to reproduce the situation in a curl test case, so that we can avoid regressions on this in the future. The case where I could reproduce a stall with the server going aways is:

A transfer

• where the upload is PAUSED
• where the download is done
• the server closes the connection

If this is indeed the situation that you are in with the etcd server (speculating here), then this points to a poor HTTP API design. Which you can probably do nothing about, I just wanted to mention it.

[icing]

Could you verify if #13271 addresses your issue?

[ligurio]

Could you verify if #13271 addresses your issue?

Sure, will do and report soon.

[ligurio]

The issue is still present with a patch on top of the master (60971d6).

Curl's output:

Captured stderr:
* !!! WARNING !!!
* This is a debug build of libcurl, do not use in production.
* STATE: INIT => CONNECT handle 0x5d9a3121cbc8; line 1910
* Curl_client_reset(), clear readers
* Added connection 0. The cache now contains 1 members
* Host localhost:2379 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
* STATE: CONNECT => CONNECTING handle 0x5d9a3121cbc8; line 1964
*   Trying [::1]:2379...
* connect to ::1 port 2379 from ::1 port 52424 failed: Connection refused
*   Trying 127.0.0.1:2379...
* Connected to localhost (127.0.0.1) port 2379
* STATE: CONNECTING => PROTOCONNECT handle 0x5d9a3121cbc8; line 2072
* STATE: PROTOCONNECT => DO handle 0x5d9a3121cbc8; line 2101
* cr_exp100_read, start AWAITING_CONTINUE
> POST /v3/watch HTTP/1.1
Host: localhost:2379
Transfer-Encoding: chunked
Accept: */*
Connection: Keep-Alive
Keep-Alive: timeout=1
Expect: 100-continue

* STATE: DO => DID handle 0x5d9a3121cbc8; line 2197
* STATE: DID => PERFORMING handle 0x5d9a3121cbc8; line 2315
* cr_exp100_read, AWAITING_CONTINUE, not expired
* HTTP 1.1 or later with persistent connection
< HTTP/1.1 100 Continue
< 
* cr_exp100_read, pass through
* cr_in_read(len=65524, total=-1, read=0) -> 0, 0, 0
* nread <= 0, server closed connection, bailing

[icing]

Thanks @ligurio for the log output. I believe I have not a correct test case for the situation and a better fix in #13271. Could you verify this? Many thanks.

[ligurio]

Could you verify this? Many thanks.

Sure. I can confirm that this version fixes the problem.

[icing]

Thanks, with the new test case in place, I hope we can avoid stumbling into this again in the future.