- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 21 Feb 2014 15:13:12 +1100
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
The other aspect of this is that HTTP already says: > A request without an Accept-Encoding header field implies that the > user agent has no preferences regarding content-codings. Although > this allows the server to use any content-coding in a response, it > does not imply that the user agent will be able to correctly process > all encodings. > > A server tests whether a content-coding for a given representation is > acceptable using these rules: > > 1. If no Accept-Encoding field is in the request, any content-coding > is considered acceptable by the user agent. ... <http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-26#section-5.3.4> So, what the current text *really* says is that servers can ignore the 'identity' content-encoding when it appears alone in the request. Cheers, On 21 Feb 2014, at 6:14 am, Martin Thomson <martin.thomson@gmail.com> wrote: > Mark raises a point on which the spec is a little vague: > > https://github.com/http2/http2-spec/issues/404 > -- > 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. > > ... 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. > -- > > I think that this is largely inherited from SPDY, but I get the sense > that there is support for the concept in general. > > I want to clarify the text above... Do we want to mandate (i.e., use > MUST) 1. gzip or 2. gzip+deflate ? > -- Mark Nottingham http://www.mnot.net/
Received on Friday, 21 February 2014 04:13:15 UTC