cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Problems switching from IPv4 to IPv6 on same URL

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Wed, 10 Aug 2016 08:28:17 +0200 (CEST)

On Tue, 9 Aug 2016, Inca R wrote:

> We send a request to http://myserver.mydomain.com while on an IPv4 address.
> After we get the response we send a new request to the same url
> https://myserver.mydomain.com but this time on an IPv6 address.
>
> cURL resolves the URL as an IPv6 address but it tries to reuse the same
> socket from the first request. We get a Network Error/Timeout.

Yes, we've seen cases like this before when sites think that the DNS entry's
lifetime somehow should work as a hint to client about the TCP connections'
lifetimes as well.

libcurl uses the host names _before_ name resolving as a hint about when to
reuse connections as it can then skip the (slow) DNS operation completely.

Normally if a site "goes away" while there's a connection kept open to it,
libcurl will detect that the connection is broken when it tries to reuse it
and then it'll take a step back, resolve the name again and do a fresh
connect.

People have previously suggested options to stop reusing a connection based on
the TTL of the DNS entry - which has the complication that we can't extract
the TTL using the current name lookup API. Others have suggested that we
should go as far as to close the connection when the DNS entry is removed from
the libcurl DNS cache[1]. The latter being way too extreme to be sensible I
think. That github issue contains a whole conversation.

Of course yet another option would be to always resolve the host name before
checking reuse and require that there's both a host name and an IP address
match.

I'm open for discussions and to help people improve this situation.

[1] = https://github.com/curl/curl/pull/403

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html
Received on 2016-08-10