Adding HTTP headers to HTTP protocol responses

Mike Hommey mh at glandium.org
Fri May 6 12:46:56 UTC 2016


Hi,

I've been looking at the wire protocol recently and found two things,
one that is wrong and one that is suboptimal, in the HTTP protocol.

The first is that the HTTP client sends a Vary header when it uses HTTP
headers to convey the protocol parameters. But Vary is not an HTTP
request header. It is a *response* header.
[ https://tools.ietf.org/html/rfc2616#section-14.44 ]

Whether it's worth setting is questionable. Arguably, it should be
Vary: *. Or even Cache-control: no-cache.
[ https://tools.ietf.org/html/rfc2616#section-14.9 ]

The second is that the response to a getbundle request is a chunked (per
https://tools.ietf.org/html/rfc2616#section-3.6.1 ) raw zlib stream. But
it's not marked as such with a Content-Encoding header (with the value
"deflate"). The difference that it makes is that a conforming user agent
can then see it can decompress the stream on its own after dechunking
it. So for instance, opening https://repo/path/?cmd=getbundle with a
browser would allow to save a raw changegroup1 or bundle2, instead of
a raw zlib stream. Or curl --compressed could be used. That would make
some kinds of debugging easier.

Now, while I'd be interested in fixing those issues, the way the wire
protocol interacts with the http server doesn't have much leeway to give
HTTP response headers.

Ideas?

Mike


More information about the Mercurial-devel mailing list