git/http.h, branch v2.41.2

treewide: remove cache.h inclusion due to object-file.h changes

2023-04-11T15:52:10Z

Signed-off-by: Elijah Newren Acked-by: Calvin Wan Signed-off-by: Junio C Hamano

git-zlib: move declarations for git-zlib functions from cache.h

2023-04-11T15:52:10Z

Move functions from cache.h for zlib.c into a new header file. Since adding a "zlib.h" would cause issues with the real zlib, rename zlib.c to git-zlib.c while we are at it. Signed-off-by: Elijah Newren Acked-by: Calvin Wan Signed-off-by: Junio C Hamano

http: prefer CURLOPT_SEEKFUNCTION to CURLOPT_IOCTLFUNCTION

2023-01-17T16:03:08Z

The IOCTLFUNCTION option has been deprecated, and generates a compiler warning in recent versions of curl. We can switch to using SEEKFUNCTION instead. It was added in 2008 via curl 7.18.0; our INSTALL file already indicates we require at least curl 7.19.4. But there's one catch: curl says we should use CURL_SEEKFUNC_{OK,FAIL}, and those didn't arrive until 7.19.5. One workaround would be to use a bare 0/1 here (or define our own macros). But let's just bump the minimum required version to 7.19.5. That version is only a minor version bump from our existing requirement, and is only a 2 month time bump for versions that are almost 13 years old. So it's not likely that anybody cares about the distinction. Switching means we have to rewrite the ioctl functions into seek functions. In some ways they are simpler (seeking is the only operation), but in some ways more complex (the ioctl allowed only a full rewind, but now we can seek to arbitrary offsets). Curl will only ever use SEEK_SET (per their documentation), so I didn't bother implementing anything else, since it would naturally be completely untested. This seems unlikely to change, but I added an assertion just in case. Likewise, I doubt curl will ever try to seek outside of the buffer sizes we've told it, but I erred on the defensive side here, rather than do an out-of-bounds read. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

remote-curl: send Accept-Language header to server

2022-07-11T19:24:28Z

Git server end's ability to accept Accept-Language header was introduced in f18604bbf2 (http: add Accept-Language header if possible, 2015-01-28), but this is only used by very early phase of the transfer, which is HTTP GET request to discover references. For other phases, like POST request in the smart HTTP, the server does not know what language the client speaks. Teach git client to learn end-user's preferred language and throw accept-language header to the server side. Once the server gets this header, it has the ability to talk to end-user with language they understand. This would be very helpful for many non-English speakers. Helped-by: Junio C Hamano Signed-off-by: Li Linchao Signed-off-by: Junio C Hamano

http: make http_get_file() external

2022-05-16T22:02:09Z

This method will be used in an upcoming extension of git-remote-curl to download a single file over HTTP(S) by request. Signed-off-by: Derrick Stolee Signed-off-by: Junio C Hamano

http: check CURLE_SSL_PINNEDPUBKEYNOTMATCH when emitting errors

2021-09-27T17:58:07Z

Change the error shown when a http.pinnedPubKey doesn't match to point the http.pinnedPubKey variable added in aeff8a61216 (http: implement public key pinning, 2016-02-15), e.g.: git -c http.pinnedPubKey=sha256/someNonMatchingKey ls-remote https://github.com/git/git.git fatal: unable to access 'https://github.com/git/git.git/' with http.pinnedPubkey configuration: SSL: public key does not match pinned public key! Before this we'd emit the exact same thing without the " with http.pinnedPubkey configuration". The advantage of doing this is that we're going to get a translated message (everything after the ":" is hardcoded in English in libcurl), and we've got a reference to the git-specific configuration variable that's causing the error. Unfortunately we can't test this easily, as there are no tests that require https:// in the test suite, and t/lib-httpd.sh doesn't know how to set up such tests. See [1] for the start of a discussion about what it would take to have divergent "t/lib-httpd/apache.conf" test setups. #leftoverbits 1. https://lore.kernel.org/git/YUonS1uoZlZEt+Yd@coredump.intra.peff.net/ Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

http: drop support for curl < 7.19.3 and < 7.17.0 (again)

2021-07-30T23:00:10Z

Remove the conditional use of CURLAUTH_DIGEST_IE and CURLOPT_USE_SSL. These two have been split from earlier simpler checks against LIBCURL_VERSION_NUM for ease of review. According to https://github.com/curl/curl/blob/master/docs/libcurl/symbols-in-versions the CURLAUTH_DIGEST_IE flag became available in 7.19.3, and CURLOPT_USE_SSL in 7.17.0. Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

http: drop support for curl < 7.19.4

2021-07-30T19:04:41Z

In the last commit we dropped support for curl < 7.16.0, let's continue that and drop support for versions older than 7.19.3. This allows us to simplify the code by getting rid of some "#ifdef"'s. Git was broken with vanilla curl < 7.19.4 from v2.12.0 until v2.15.0. Compiling with it was broken by using CURLPROTO_* outside any "#ifdef" in aeae4db174 (http: create function to get curl allowed protocols, 2016-12-14), and fixed in v2.15.0 in f18777ba6ef (http: fix handling of missing CURLPROTO_*, 2017-08-11). It's unclear how much anyone was impacted by that in practice, since as noted in [1] RHEL versions using curl older than that still compiled, because RedHat backported some features. Perhaps other vendors did the same. Still, it's one datapoint indicating that it wasn't in active use at the time. That (the v2.12.0 release) was in Feb 24, 2017, with v2.15.0 on Oct 30, 2017, it's now mid-2021. 1. http://lore.kernel.org/git/c8a2716d-76ac-735c-57f9-175ca3acbcb0@jupiterrise.com; followed-up by f18777ba6ef (http: fix handling of missing CURLPROTO_*, 2017-08-11) Signed-off-by: Jeff King Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

http: drop support for curl < 7.16.0

2021-07-30T16:11:15Z

In the last commit we dropped support for curl < 7.11.1, let's continue that and drop support for versions older than 7.16.0. This allows us to get rid of some now-obsolete #ifdefs. Choosing 7.16.0 is a somewhat arbitrary cutoff: 1. It came out in October of 2006, almost 15 years ago. Besides being a nice round number, around 10 years is a common end-of-life support period, even for conservative distributions. 2. That version introduced the curl_multi interface, which gives us a lot of bang for the buck in removing #ifdefs RHEL 5 came with curl 7.15.5[1] (released in August 2006). RHEL 5's extended life cycle program ended on 2020-11-30[1]. RHEL 6 comes with curl 7.19.7 (released in November 2009), and RHEL 7 comes with 7.29.0 (released in February 2013). 1. http://lore.kernel.org/git/873e1f31-2a96-5b72-2f20-a5816cad1b51@jupiterrise.com Signed-off-by: Jeff King Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano

http: drop support for curl < 7.11.1

2021-07-30T16:11:15Z

Drop support for this ancient version of curl and simplify the code by allowing us get rid of some "#ifdef"'s. Git will not build with vanilla curl older than 7.11.1 due our use of CURLOPT_POSTFIELDSIZE in 37ee680d9b (http.postbuffer: allow full range of ssize_t values, 2017-04-11). This field was introduced in curl 7.11.1. We could solve these compilation problems with more #ifdefs, but it's not worth the trouble. Version 7.11.1 came out in March of 2004, over 17 years ago. Let's declare that too old and drop any existing ifdefs that go further back. One obvious benefit is that we'll have fewer conditional bits cluttering the code. This patch drops all #ifdefs that reference older versions (note that curl's preprocessor macros are in hex, so we're looking for 070b01, not 071101). Signed-off-by: Jeff King Signed-off-by: Ævar Arnfjörð Bjarmason Signed-off-by: Junio C Hamano