From: "Torsten Bögershausen" <tboegi@web.de>
To: Mike Hommey <mh@glandium.org>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH v7 1/9] connect: document why we sometimes call get_port after get_host_and_port
Date: Thu, 26 May 2016 07:35:23 +0200 [thread overview]
Message-ID: <57468B1B.4080604@web.de> (raw)
In-Reply-To: <20160525233403.GA23405@glandium.org>
On 05/26/2016 01:34 AM, Mike Hommey wrote:
> On Tue, May 24, 2016 at 06:44:26AM +0200, Torsten Bögershausen wrote:
>> On 05/23/2016 11:30 PM, Junio C Hamano wrote:
>>> Torsten Bögershausen <tboegi@web.de> writes:
>>>
>>>>>>> get_host_and_port(&ssh_host, &port);
>>>>>>> + /* get_host_and_port may not return a port
>>>>>>> even when
>>>>>>> + * there is one: In the [host:port]:path case,
>>>>>>> + * get_host_and_port is called with "[host:port]" and
>>>>>>> + * returns "host:port" and NULL.
>>>>>>> + * In that specific case, we still need to split the
>>>>>>> + * port. */
>>>>>> Is it worth to mention that this case is "still supported legacy" ?
>>>>> If it's worth mentioning anywhere, it seems to me it would start with
>>>>> urls.txt?
>>>>>
>>>>> Mike
>>>>>
>>>> I don't know.
>>>> urls.txt is for Git users, and connect.c is for Git developers.
>>>> urls.txt does not mention that Git follows any RFC when parsing the
>>>> URLS', it doesn't claim to be 100% compliant.
>>>> Even if it makes sense to do so, as many user simply expect Git to accept
>>>> RFC compliant URL's, and it makes the development easier, if there is
>>>> an already
>>>> written specification, that describes all the details.
>>>> The parser is not 100% RFC compliant, one example:
>>>> - old-style usgage like "git clone [host:222]:~/path/to/repo are supported
>>> Is it an option to fix get_host_and_port() so that it returns what
>>> the caller expects even when it is given "[host:port]"? When the
>>> caller passes other forms like "host:port", it expects to get "host"
>>> and "port" parsed out into two variables. Why can't the caller
>>> expect to see the same happen when feeding "[host:port]" to the
>>> function?
>>>
>> This is somewhat out of my head:
>> git clone git://[example.com:123]:/test #illegal, malformated URL
>> git clone [example.com:123]:/test #scp-like URL, legacy
>> git clone ssh://[example.com:123]:/test #illegal, but supported as
>> legacy, because
>> git clone ssh://[user@::1]/test # was the only way to
>> specify a user name at a literal IPv6 address
>>
>> May be we should have some more test cases for malformated git:// URLs?
>
> None of these malformed urls are rejected with or without my series
> applied:
>
> Without:
> $ git fetch-pack --diag-url git://[example.com:123]:/test
> Diag: url=git://[example.com:123]:/test
> Diag: protocol=git
> Diag: hostandport=[example.com:123]:
> Diag: path=/test
> $ git fetch-pack --diag-url
> ssh://[example.com:123]:/test
> Diag: url=ssh://[example.com:123]:/test
> Diag: protocol=ssh
> Diag: userandhost=example.com
> Diag: port=123
> Diag: path=/test
>
> With:
> $ git fetch-pack --diag-url git://[example.com:123]:/test
> Diag: url=git://[example.com:123]:/test
> Diag: protocol=git
> Diag: user=NULL
> Diag: host=example.com
> Diag: port=123
> Diag: path=/test
> $ git fetch-pack --diag-url ssh://[example.com:123]:/test
> Diag: url=ssh://[example.com:123]:/test
> Diag: protocol=ssh
> Diag: user=NULL
> Diag: host=example.com
> Diag: port=123
> Diag: path=/test
>
> Note in the first case, hostandport is "[example.com:123]:", and that
> is treated as host=example.com:123 and port=NULL further down, so my
> series is changing something here, but arguably, it makes it less worse.
> (note that both with and without my series,
> "git://[example.com:123]:42/path" is treated the same, so only a corner
> case changed)
>
> Can we go forward with the current series (modulo the comment style
> thing Eric noted, and maybe adding a note about the parser handling urls
> as per urls.txt), and not bloat scope it? If anything, the state of the
> code after the series should make further parser changes easier.
>
> Cheers,
>
> Mike
>
Thanks for digging.
How about something like this:
/*
* get_host_and_port may not return a port in the [host:port]:path case.
* To support this undocumented legacy we still need to split the port.
*/
next prev parent reply other threads:[~2016-05-26 5:36 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-21 23:17 [PATCH v7 0/9] connect: various cleanups Mike Hommey
2016-05-21 23:17 ` [PATCH v7 1/9] connect: document why we sometimes call get_port after get_host_and_port Mike Hommey
2016-05-22 2:40 ` Eric Sunshine
2016-05-22 6:07 ` Torsten Bögershausen
2016-05-22 8:03 ` Mike Hommey
2016-05-23 4:31 ` Torsten Bögershausen
2016-05-23 21:30 ` Junio C Hamano
2016-05-23 21:50 ` Mike Hommey
2016-05-24 4:44 ` Torsten Bögershausen
2016-05-25 23:34 ` Mike Hommey
2016-05-26 5:35 ` Torsten Bögershausen [this message]
2016-05-21 23:17 ` [PATCH v7 2/9] connect: call get_host_and_port() earlier Mike Hommey
2016-05-21 23:17 ` [PATCH v7 3/9] connect: re-derive a host:port string from the separate host and port variables Mike Hommey
2016-05-21 23:17 ` [PATCH v7 4/9] connect: make parse_connect_url() return separated host and port Mike Hommey
2016-05-21 23:17 ` [PATCH v7 5/9] connect: group CONNECT_DIAG_URL handling code Mike Hommey
2016-05-21 23:17 ` [PATCH v7 6/9] connect: make parse_connect_url() return the user part of the url as a separate value Mike Hommey
2016-05-21 23:17 ` [PATCH v7 7/9] connect: change the --diag-url output to separate user and host Mike Hommey
2016-05-21 23:17 ` [PATCH v7 8/9] connect: actively reject git:// urls with a user part Mike Hommey
2016-05-21 23:17 ` [PATCH v7 9/9] connect: move ssh command line preparation to a separate function Mike Hommey
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=57468B1B.4080604@web.de \
--to=tboegi@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=mh@glandium.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).