summaryrefslogtreecommitdiff
path: root/Documentation/config/http.txt
diff options
context:
space:
mode:
authorLibravatar Jeff King <peff@peff.net>2020-04-14 17:43:04 -0400
committerLibravatar Junio C Hamano <gitster@pobox.com>2020-04-15 10:31:03 -0700
commit4c5971e18a181c68aec03262fb467cb5d21a5b0d (patch)
treeb7873c08d07c94ddafbaeaf300ea17e2d7b5828e /Documentation/config/http.txt
parentGit 2.26.1 (diff)
downloadtgif-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 'Documentation/config/http.txt')
0 files changed, 0 insertions, 0 deletions