quoted
quoted
quoted
quoted
"Daniel" == Daniel Stenberg [off-list ref] writes:
quoted
I just noticed that, given a remote URL with a hostname which has
both A and AAAA RRs in the DNS, git-fetch will retry a git-protocol
fetch using the v4 address if the v6 address is unreachable, but
will not do so when the remote is an http URL.
Daniel> Isn't this simply because libcurl (used for http) has no retry
Daniel> functionality on this scenario while git itself has that for the
Daniel> git protocol?
Yes, that is true.
But git could be smarter about it. libcurl has CURLOPT_IPRESOLVE which
can be set to any of CURL_IPRESOLVE_WHATEVER, CURL_IPRESOLVE_V4 or
CURL_IPRESOLVE_V6. Git could at least allow setting that via a config
option and/or an env var, just like it does for libcurl options like
CURLOPT_LOW_SPEED_LIMIT.
Even better would be to set CURLOPT_CONNECT_ONLY and then try with
CURL_IPRESOLVE_WHATEVER, CURL_IPRESOLVE_V6 and CURL_IPRESOLVE_V4 in turn
until it gets a connection, and then use CURLINFO_LASTSOCKET and the
full URL to do the GET.
-JimC
--
James Cloos [off-list ref] OpenPGP: 1024D/ED7DAEA6
On Tue, 3 Jun 2008, James Cloos wrote:
But git could be smarter about it. libcurl has CURLOPT_IPRESOLVE which can
be set to any of CURL_IPRESOLVE_WHATEVER, CURL_IPRESOLVE_V4 or
CURL_IPRESOLVE_V6. Git could at least allow setting that via a config
option and/or an env var, just like it does for libcurl options like
CURLOPT_LOW_SPEED_LIMIT.
Perhaps, but I thought the git protocol behavior was to dynamicly back off a
failed connect attempt to try the next? That wouldn't be solvable with any
preset option. It needs code added to/changed in libcurl.
Even better would be to set CURLOPT_CONNECT_ONLY and then try with
CURL_IPRESOLVE_WHATEVER, CURL_IPRESOLVE_V6 and CURL_IPRESOLVE_V4 in turn
until it gets a connection, and then use CURLINFO_LASTSOCKET and the full
URL to do the GET.
Eeek. I really disagree with this suggestion. CURLOPT_CONNECT_ONLY means you
only (TCP or over proxy) connect and nothing more. That would force git to
implement a lot of HTTP details that libcurl already provides.
If you really really insist on letting git do it and not bring this feature to
libcurl, then I'd suggest that you first resolve the host, verify it by any
means you see fit, and then pass the IP to libcurl like in the URL as
"HTTP://12.23.45.67/blabla" with the correct host name in a custom-provided
host: header. It'd let you do the resolving magic and let libcurl do the HTTP
magic. But I wouldn't recommend that either...
--
/ daniel.haxx.se - primary libcurl author