Re: git 2.3.4, ssh: Could not resolve hostname

["Kyle J. McKay" <mackyle@gmail.com>]

On Apr 2, 2015, at 17:02, Torsten Bögershausen wrote:

> On 2015-04-02 21.35, Jeff King wrote:
>> On Thu, Apr 02, 2015 at 12:31:14PM -0700, Reid Woodbury Jr. wrote:
>>
>>> Ah, understand. Here's my project URL for 'remote "origin"' with a
>>> more meaningful representation of their internal FQDN:
>>>
>>> 	url = ssh://rwoodbury@systemname.groupname.online:/opt/git/inventory.git
>>>
>>> The "online" is their literal internal TLD.
>>
>> Thanks. The problem is the extra ":" after "online"; your URL is
>> malformed. You can just drop that colon entirely.
>>
>> I do not think we need to support this syntax going forward (the  
>> colon
>> is meaningless here, and our documentation is clear that it should go
>> with a port number), but on the other hand, it might be nice to be  
>> more
>> liberal, as we were in v2.3.3 and prior. I'll leave it to Torsten  
>> to see
>> whether supporting that would hurt some of the other cases, or  
>> whether
>> it would make the code too awkward.
>>
>> -Peff
>
> Thanks for digging.
>
> This makes my think that it is
> a) non-standard to have the extra colon

It's not.  See RFC 3986 appendix A:

   authority = [ userinfo "@" ] host [ ":" port ]

   port = *DIGIT

"*DIGIT" means (see RFC 2234 section 3.6) zero or more digits.

> b) The error message could be better
> c) We don't have a test case
> d) This reminds my of an improvement from Linus:
> 608d48b2207a61528
> ......
>    So when somebody passes me a "please pull" request pointing to  
> something
>    like the following
>
>    	git://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git
>
>    (note the extraneous colon at the end of the host name), git  
> would happily
>    try to connect to port 0, which would generally just cause the  
> remote to
>    not even answer, and the "connect()" will take a long time to  
> time out.
> .....
>
> Sorry guys for the regression, the old parser handled the extra  
> colon as "port 0",
> the new one looks for the "/" as the end of the hostname (and the  
> beginning of the path)
>
> Either we accept the extra colon as before, or the parser puts out a  
> better error message,

[...]

> Spontaneously I would say that a trailing ':' at the end of a  
> hostname in the ssh:// scheme
> can be safely ignored, what do you think ?

You know, there is a "url_normalize" routine in urlmatch.h/urlmatch.c  
that checks for a lot of these things and provides a translated error  
message if there's a problem as well as normalizing and separating out  
the various parts of the URL.  It does not currently handle default  
ports for anything other than http[s] but it would be simple enough to  
add support for ssh, git, ftp[s] and rsync default ports too.

-Kyle