Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: libcurl multi timeout after IP or routing table changes
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Silas via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 27 Jan 2022 16:38:47 -0300
On Thu, Jan 27, 2022 at 08:20:31AM +0100, Daniel Stenberg wrote:
> I don't think it's related to TLS. If it was, you should be able to repro
> using HTTPS using HTTP/1.1 as well. I rather suspect it is about HTTP/2 and
> that each transfer is a stream inside a connection, so a failed transfer
> only kills that stream and not the connection.
Indeed! When I force HTTP version to 1.1 (with CURL_HTTP_VERSION_1_1) I don't
observe the problem anymore. It can reconnect to the server even though I change
IP and the routing table.
> When you spot the problem with HTTP/2. Are the three transfers to the same
> host? Are they perhaps even using the same connection?
Yes, I'm testing against https://example.com . I don't know how I can check if
they are using the same connection.
Is this HTTP 2 specific thing a bug? Should I open an issue in the bug tracker
or is this email thread enough?
For me the problem is solved, since, for my needs, HTTP 1.1 is OK.
Thanks again.
Date: Thu, 27 Jan 2022 16:38:47 -0300
On Thu, Jan 27, 2022 at 08:20:31AM +0100, Daniel Stenberg wrote:
> I don't think it's related to TLS. If it was, you should be able to repro
> using HTTPS using HTTP/1.1 as well. I rather suspect it is about HTTP/2 and
> that each transfer is a stream inside a connection, so a failed transfer
> only kills that stream and not the connection.
Indeed! When I force HTTP version to 1.1 (with CURL_HTTP_VERSION_1_1) I don't
observe the problem anymore. It can reconnect to the server even though I change
IP and the routing table.
> When you spot the problem with HTTP/2. Are the three transfers to the same
> host? Are they perhaps even using the same connection?
Yes, I'm testing against https://example.com . I don't know how I can check if
they are using the same connection.
Is this HTTP 2 specific thing a bug? Should I open an issue in the bug tracker
or is this email thread enough?
For me the problem is solved, since, for my needs, HTTP 1.1 is OK.
Thanks again.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.htmlReceived on 2022-01-27