{"thread":{"id":"13742","subject":"git-fetch vs ipv6 routing issues","startedAt":"2008-05-31T17:56:01Z","lastAt":"2008-06-03T23:56:01Z","messageCount":5,"participants":["James Cloos","Daniel Stenberg"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"78238","messageId":"m38wxq1hou.fsf@eagle.jhcloos.com","threadId":"13742","inReplyTo":null,"subject":"git-fetch vs ipv6 routing issues","fromName":"James Cloos","fromEmail":"cloos@jhcloos.com","sentAt":"2008-05-31T17:56:01Z","receivedAt":"2008-05-31T17:56:01Z","isPatch":false,"sender":{"key":"cloos@jhcloos.com","avatar":"https://gravatar.com/avatar/ec9a05787d29afe41e243e4b60bd0e2f69d757688e8f0bfe5e78bc185a3e317f?d=mp&s=160"},"body":"I just noticed that, given a remote URL with a hostname which has both A\nand AAAA RRs in the DNS, git-fetch will retry a git-protocol fetch using\nthe v4 address if the v6 address is unreachable, but will not do so when\nthe remote is an http URL.\n\n(I'm currently running bdb87afb4b4 from last month but will be updating\nlater today. I don't see any relevant changes in the git log between\nthen and now.)\n\n-JimC\n-- \ncloos@jhcloos.com\n"},{"id":"78276","messageId":"alpine.LRH.1.10.0806010924340.27605@yvahk3.pbagnpgbe.fr","threadId":"13742","inReplyTo":"m38wxq1hou.fsf@eagle.jhcloos.com","subject":"Re: git-fetch vs ipv6 routing issues","fromName":"Daniel Stenberg","fromEmail":"daniel@haxx.se","sentAt":"2008-06-01T07:25:30Z","receivedAt":"2008-06-01T07:25:30Z","isPatch":false,"sender":{"key":"daniel@haxx.se","avatar":"https://gravatar.com/avatar/69fdca87edd17cee21ca2e79fc2ff671d644603c3dc27167430f3cd3dbab7ba8?d=mp&s=160"},"body":"On Sat, 31 May 2008, James Cloos wrote:\n\n> I just noticed that, given a remote URL with a hostname which has both A and \n> AAAA RRs in the DNS, git-fetch will retry a git-protocol fetch using the v4 \n> address if the v6 address is unreachable, but will not do so when the remote \n> is an http URL.\n\nIsn't this simply because libcurl (used for http) has no retry functionality \non this scenario while git itself has that for the git protocol?\n\n-- \n\n / daniel.haxx.se\n"},{"id":"78535","messageId":"m3wsl6guqg.fsf@lugabout.jhcloos.org","threadId":"13742","inReplyTo":"alpine.LRH.1.10.0806010924340.27605@yvahk3.pbagnpgbe.fr","subject":"Re: git-fetch vs ipv6 routing issues","fromName":"James Cloos","fromEmail":"cloos@jhcloos.com","sentAt":"2008-06-03T19:53:52Z","receivedAt":"2008-06-03T19:53:52Z","isPatch":false,"sender":{"key":"cloos@jhcloos.com","avatar":"https://gravatar.com/avatar/ec9a05787d29afe41e243e4b60bd0e2f69d757688e8f0bfe5e78bc185a3e317f?d=mp&s=160"},"body":">>>>> \"Daniel\" == Daniel Stenberg writes:\n\n>> I just noticed that, given a remote URL with a hostname which has\n>> both A and AAAA RRs in the DNS, git-fetch will retry a git-protocol\n>> fetch using the v4 address if the v6 address is unreachable, but\n>> will not do so when the remote is an http URL.\n\nDaniel> Isn't this simply because libcurl (used for http) has no retry\nDaniel> functionality on this scenario while git itself has that for the\nDaniel> git protocol?\n\nYes, that is true.\n\nBut git could be smarter about it. libcurl has CURLOPT_IPRESOLVE which\ncan be set to any of CURL_IPRESOLVE_WHATEVER, CURL_IPRESOLVE_V4 or\nCURL_IPRESOLVE_V6. Git could at least allow setting that via a config\noption and/or an env var, just like it does for libcurl options like\nCURLOPT_LOW_SPEED_LIMIT.\n\nEven better would be to set CURLOPT_CONNECT_ONLY and then try with\nCURL_IPRESOLVE_WHATEVER, CURL_IPRESOLVE_V6 and CURL_IPRESOLVE_V4 in turn\nuntil it gets a connection, and then use CURLINFO_LASTSOCKET and the\nfull URL to do the GET.\n\n-JimC\n-- \nJames Cloos OpenPGP: 1024D/ED7DAEA6\n"},{"id":"78549","messageId":"alpine.LRH.1.10.0806032242050.10782@yvahk3.pbagnpgbe.fr","threadId":"13742","inReplyTo":"m3wsl6guqg.fsf@lugabout.jhcloos.org","subject":"Re: git-fetch vs ipv6 routing issues","fromName":"Daniel Stenberg","fromEmail":"daniel@haxx.se","sentAt":"2008-06-03T20:50:16Z","receivedAt":"2008-06-03T20:50:16Z","isPatch":false,"sender":{"key":"daniel@haxx.se","avatar":"https://gravatar.com/avatar/69fdca87edd17cee21ca2e79fc2ff671d644603c3dc27167430f3cd3dbab7ba8?d=mp&s=160"},"body":"On Tue, 3 Jun 2008, James Cloos wrote:\n\n> But git could be smarter about it. libcurl has CURLOPT_IPRESOLVE which can \n> be set to any of CURL_IPRESOLVE_WHATEVER, CURL_IPRESOLVE_V4 or \n> CURL_IPRESOLVE_V6. Git could at least allow setting that via a config \n> option and/or an env var, just like it does for libcurl options like \n> CURLOPT_LOW_SPEED_LIMIT.\n\nPerhaps, but I thought the git protocol behavior was to dynamicly back off a \nfailed connect attempt to try the next? That wouldn't be solvable with any \npreset option. It needs code added to/changed in libcurl.\n\n> Even better would be to set CURLOPT_CONNECT_ONLY and then try with \n> CURL_IPRESOLVE_WHATEVER, CURL_IPRESOLVE_V6 and CURL_IPRESOLVE_V4 in turn \n> until it gets a connection, and then use CURLINFO_LASTSOCKET and the full \n> URL to do the GET.\n\nEeek. I really disagree with this suggestion. CURLOPT_CONNECT_ONLY means you \nonly (TCP or over proxy) connect and nothing more. That would force git to \nimplement a lot of HTTP details that libcurl already provides.\n\nIf you really really insist on letting git do it and not bring this feature to \nlibcurl, then I'd suggest that you first resolve the host, verify it by any \nmeans you see fit, and then pass the IP to libcurl like in the URL as \n\"HTTP://12.23.45.67/blabla\" with the correct host name in a custom-provided \nhost: header. It'd let you do the resolving magic and let libcurl do the HTTP \nmagic. But I wouldn't recommend that either...\n\n-- \n\n / daniel.haxx.se - primary libcurl author\n"},{"id":"78572","messageId":"m3prqygjiv.fsf@lugabout.jhcloos.org","threadId":"13742","inReplyTo":"alpine.LRH.1.10.0806032242050.10782@yvahk3.pbagnpgbe.fr","subject":"Re: git-fetch vs ipv6 routing issues","fromName":"James Cloos","fromEmail":"cloos@jhcloos.com","sentAt":"2008-06-03T23:56:01Z","receivedAt":"2008-06-03T23:56:01Z","isPatch":false,"sender":{"key":"cloos@jhcloos.com","avatar":"https://gravatar.com/avatar/ec9a05787d29afe41e243e4b60bd0e2f69d757688e8f0bfe5e78bc185a3e317f?d=mp&s=160"},"body":">>>>> \"Daniel\" == Daniel Stenberg writes:\n\nDaniel> Eeek. I really disagree with this suggestion. CURLOPT_CONNECT_ONLY\nDaniel> means you only (TCP or over proxy) connect and nothing more. That\nDaniel> would force git to implement a lot of HTTP details that libcurl\nDaniel> already provides.\n\nOK. Then I misread that section of the curl_easy_setopt(3) man page.\n\nI do think git should be able to do this even when compiled against\nlegacy versions of libcurl, though.\n\n(Of course, even better would be the ability to aviod http altogether.\nBut some projects I track are only available via http urls....)\n\n-JimC\n-- \nJames Cloos OpenPGP: 1024D/ED7DAEA6\n"}]}