Enable info/refs gzip decompression in HTTP client
authorShawn O. Pearce <spearce@spearce.org>
Wed, 19 Sep 2012 23:12:02 +0000 (16:12 -0700)
committerJunio C Hamano <gitster@pobox.com>
Thu, 20 Sep 2012 17:26:50 +0000 (10:26 -0700)
commitaa90b9697f9275e4f9cb10d274495e7587f217c0
tree0a76cc125c8c2ad79080cadd4c98644dd1f1049a
parent25ae7cfd19c8f21721363c64163cd5d9d1135b20
Enable info/refs gzip decompression in HTTP client

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.

Only request gzip encoding from servers. Although deflate is
supported by libcurl, most servers have standardized on gzip
encoding for compression as that is what most browsers support.
Asking for deflate increases request sizes by a few bytes, but is
unlikely to ever be used by a server.

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.

Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
http.c
remote-curl.c
t/t5551-http-fetch.sh