Re: [PATCH 1/3] connect.c: Improve parsing of literal IPV6 addresses

["Torsten Bögershausen" <tboegi@web.de>]

On 2015-01-22 21.07, brian m. carlson wrote:
> On Mon, Jan 19, 2015 at 06:21:24PM +0100, Torsten Bögershausen wrote:
>> When parsing an URL, older Git versions did handle
>> URLs like ssh://2001:db8::1/repo.git the same way as
>> ssh://[2001:db8::1]/repo.git
>>
>> Commit 83b058 broke the parsing of IPV6 adresses without "[]":
>> It was written in mind that the fist ':' in a URL was the beginning of a
>> port number, while the old code was more clever:
>> Literal IPV6 addresses have always at least two ':'.
>> When the "hostandport" had a ':' and the rest of the hostandport string
>> could be parsed into an integer between 0 and 65536, then it was used
>> as a port number, like "host:22".
>> Otherwise the first ':' was assumed to be part of a literal IPV6 address,
>> like "ssh://[2001:db8::1]/repo.git" or "ssh://[::1]/repo.git".
>>
>> Re-introduce the old parsing in get_host_and_port().
>>
>> Improve the parsing to handle URLs which have a user name and a literal
>> IPV6 like "ssh://user@[2001:db8::1]/repo.git".
>> (Thanks to Christian Taube <lists@hcf.yourweb.de> for reporting this long
>> standing issue)
>>
>> Another regression was introduced in 83b058:
>> A non-RFC conform URL like "[localhost:222]" could be used in older versions
>> of Git to connect to run "ssh -p 222 localhost".
>> The new stricter parsing did not allow this any more.
>> See even 8d3d28f5dba why "[localhost:222]" should be declared a feature.
> 
> I'm not sure this is a very good idea.  While this may have worked in the past, it's also completely inconsistent with the way all non-SSH URLs work in Git:
> 
>  vauxhall ok % git push https://bmc@2001:470:1f05:79::1/git/bmc/homedir.git master
>  fatal: unable to access 'https://bmc@2001:470:1f05:79::1/git/bmc/homedir.git/': IPv6 numerical address used in URL without brackets
> 
>  vauxhall no % git push https://bmc@[castro.crustytoothpaste.net]/git/bmc/homedir.git master
>  fatal: unable to access 'https://bmc@[castro.crustytoothpaste.net]/git/bmc/homedir.git/': Could not resolve host: [castro.crustytoothpaste.net]
> 
>  vauxhall no % git push https://bmc@[castro.crustytoothpaste.net:443]/git/bmc/homedir.git master
>  fatal: unable to access 'https://bmc@[castro.crustytoothpaste.net:443]/git/bmc/homedir.git/': Could not resolve host: [castro.crustytoothpaste.net
> 
> I would argue that people using IPv6 literals in URLs should already know how to do it correctly, and the consistency between SSH and HTTPS URLs is a feature, not a bug.  In the non-URL SSH form, you still have to use the bracketed form to deal with the case in which somebody creates a directory called "1" in their home directory and writes:
> 
We want to support ssh://bmc@2001:470:1f05:79::1/git/bmc/homedir.git/
   because e.g. the Git shipped with Debian (1.7.10.4) (and a lot of other installations) supports it.

We want to support ssh://bmc@[2001:470:1f05:79::1]/git/bmc/homedir.git/
    because that is what other people may expect to work as well:
 ssh://bmc@[2001:470:1f05:79::1]:4444/git/bmc/homedir.git/
 
>  git push 2001:470:1f05:79::1:1 master
> when they mean
> 
>  git push [2001:470:1f05:79::1]:1 master
That I don't understand this, where is the path name in your example ?

Everything after the first ':' is the path in the short form:
bmc@hostxx:/git/bmc/homedir.git/

If you really want to use a literal IPV6 with the short form, you must use the brackets:
bmc@[2001:470:1f05:79::1]:/git/bmc/homedir.git/
(And you can not have a port number here)


Nobody forces somebody to use any specific form.