Requiring GZIP and Deflate

[mnot]

9.3 GZip Content-Encoding says:

Clients MUST support gzip compression for HTTP request bodies. Regardless of the value of the accept-encoding header field, a server MAY send responses with gzip or deflate encoding.

A few things here:

1. My understanding is that people want this so that intermediaries can't strip encoding and therefore impact performance. However, AIUI those same people intend to always run HTTP/2 over TLS, so I wonder if this is really necessary.

If we keep this text, a few requests:

1. Is it both gzip and deflate (which last I checked, some clients don't support)? If so, the first sentence and section title should be changed to reflect this.
2. The implication on a HTTP/1 to HTTP/2 intermediary should be spelled out -- that they MUST decompress the response body if the HTTP/1 client doesn't advertise support for the compression used.

[martinthomson]

Sounds reasonable. I assume the design issue here for discussion is the first (i.e., gzip or gzip+deflate) ?

[jpinner]

My understanding of the intent is that both gzip and deflate encoding must be supported by the client -- but happy to ask the list :)

[grmocg]

That was the original intent.
I can't think of a truly good reason that both MUST be supported (so long
as one is), but most libraries do both if they do one..

On Wed, Feb 19, 2014 at 9:40 PM, Jeff Pinner [email protected]:

My understanding of the intent is that both gzip and deflate encoding must
be supported by the client -- but happy to ask the list :)

Reply to this email directly or view it on GitHubhttps://github.com//issues/404#issuecomment-35590944
.

[mnot]

@martinthomson - yes. Will probably just bring it up in London, given the timing.

[mnot]

Discussed in London; gzip only + editorial massaging.