diff options
author | Jeff King <peff@peff.net> | 2020-04-14 17:43:04 -0400 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2020-04-15 10:31:03 -0700 |
commit | 4c5971e18a181c68aec03262fb467cb5d21a5b0d (patch) | |
tree | b7873c08d07c94ddafbaeaf300ea17e2d7b5828e /t/t5100/patch0018 | |
parent | Git 2.26.1 (diff) | |
download | tgif-4c5971e18a181c68aec03262fb467cb5d21a5b0d.tar.xz |
credential: treat "?" and "#" in URLs as end of host
It's unusual to see:
https://example.com?query-parameters
without an intervening slash, like:
https://example.com/some-path?query-parameters
or even:
https://example.com/?query-parameters
but it is a valid end to the hostname (actually "authority component")
according to RFC 3986. Likewise for "#".
And curl will parse the URL according to the standard, meaning it will
contact example.com, but our credential code would ask about a bogus
hostname with a "?" in it. Let's make sure we follow the standard, and
more importantly ask about the same hosts that curl will be talking to.
It would be nice if we could just ask curl to parse the URL for us. But
it didn't grow a URL-parsing API until 7.62, so we'd be stuck with
fallback code either way. Plus we'd need this code in the main Git
binary, where we've tried to avoid having a link dependency on libcurl.
But let's at least fix our parser. Moving to curl's parser would prevent
other potential discrepancies, but this gives us immediate relief for
the known problem, and would help our fallback code if we eventually use
curl.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 't/t5100/patch0018')
0 files changed, 0 insertions, 0 deletions