"Shawn O. Pearce" <spearce@xxxxxxxxxxx> writes: > From: "Shawn O. Pearce" <spearce@xxxxxxxxxxx> > > 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html