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

> From: "Shawn O. Pearce" <spea...@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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to