Re: [PATCH v2 1/2] remote-curl: accept all encodings supported by curl

On Wed, 23 May 2018, Junio C Hamano wrote: -> Accept-Encoding: gzip +> Accept-Encoding: ENCODINGS Is the ordering of these headers determined by the user of cURL library (i.e. Git), or whatever the version of cURL we happened to link with happens to produce? The point is whether the order

Re: [PATCH v2 1/2] remote-curl: accept all encodings supported by curl

On Wed, May 23, 2018 at 10:23:26AM +0900, Junio C Hamano wrote: > Similarly, how much control do we have to ensure that the test HTTPD > server (1) supports gzip and (2) does not support encoding algos > with confusing names e.g. "funnygzipalgo" that may accidentally > match that pattern? I feel

Re: [PATCH v2 1/2] remote-curl: accept all encodings supported by curl

Brandon Williams writes: > diff --git a/t/t5551-http-fetch-smart.sh b/t/t5551-http-fetch-smart.sh > index f5721b4a5..913089b14 100755 > --- a/t/t5551-http-fetch-smart.sh > +++ b/t/t5551-http-fetch-smart.sh > @@ -26,14 +26,14 @@ setup_askpass_helper > cat >exp < > GET

Re: [PATCH v2 1/2] remote-curl: accept all encodings supported by curl

Brandon Williams wrote: > Configure curl to accept all encodings which curl supports instead of > only accepting gzip responses. > > This fixes an issue when using an installation of curl which is built > without the "zlib" feature. Since aa90b9697 (Enable info/refs gzip > decompression in HTTP

[PATCH v2 1/2] remote-curl: accept all encodings supported by curl

Configure curl to accept all encodings which curl supports instead of only accepting gzip responses. This fixes an issue when using an installation of curl which is built without the "zlib" feature. Since aa90b9697 (Enable info/refs gzip decompression in HTTP client, 2012-09-19) we end up