From: Junio C Hamano <gitster@pobox.com>
Date: Thu, 20 Sep 2012 00:43:24 GMT
Subject: Re: [PATCH] Enable info/refs gzip decompression in HTTP client
Message-ID: <7vtxutcymr.fsf@alter.siamese.dyndns.org>
In-Reply-To: <1348096322-21426-1-git-send-email-spearce@spearce.org>

"Shawn O. Pearce" <spearce@spearce.org> writes:

> From: "Shawn O. Pearce" <spearce@spearce.org>
>
> Some HTTP servers try to use gzip compression on the /info/refs
> request to save transfer bandwidth. Repositories with many tags
> may find the /info/refs request can be gzipped to be 50% of the
> original size due to the few but often repeated bytes used (hex
> SHA-1 and commonly digits in tag names).
>
> For most HTTP requests enable "Accept-Encoding: gzip" ensuring
> the /info/refs payload can use this encoding format.
>
> Disable the Accept-Encoding header on probe RPCs as response bodies
> are supposed to be exactly 4 bytes long, "0000". The HTTP headers
> requesting and indicating compression use more space than the data
> transferred in the body.

All of the above sounds very convincing, but ...

> diff --git a/t/t5551-http-fetch.sh b/t/t5551-http-fetch.sh
> index 2db5c35..380c175 100755
> --- a/t/t5551-http-fetch.sh
> +++ b/t/t5551-http-fetch.sh
> @@ -32,13 +32,14 @@ setup_askpass_helper
>  cat >exp <<EOF
>  > GET /smart/repo.git/info/refs?service=git-upload-pack HTTP/1.1
>  > Accept: */*
> +> Accept-Encoding: gzip
>  > Pragma: no-cache
>  < HTTP/1.1 200 OK
>  < Pragma: no-cache
>  < Cache-Control: no-cache, max-age=0, must-revalidate
>  < Content-Type: application/x-git-upload-pack-advertisement
>  > POST /smart/repo.git/git-upload-pack HTTP/1.1
> -> Accept-Encoding: deflate, gzip
> +> Accept-Encoding: gzip

... was loss of "deflate" intended?  If so why?  Could you explain
it in the log message?

>  > Content-Type: application/x-git-upload-pack-request
>  > Accept: application/x-git-upload-pack-result
>  > Content-Length: xxx