On Tue, 3 Jun 2008, James Cloos wrote:

quoted text
> 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.

quoted text
> 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html