Re: git 2.3.4, ssh: Could not resolve hostname
- From
Kyle J. McKay <mackyle@gmail.com>
- Date
- Apr 3, 2015, 21:32 UTC
- Message-ID
- <51689E6C-93FD-4E77-8FF3-BB8EC7EA735A@gmail.com>
- In-Reply-To
- <551DD887.2010403@web.de>
On Apr 2, 2015, at 17:02, Torsten Bögershausen wrote:
Show 30 quoted lines
> 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.
Show 26 quoted lines
> 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