- From: Patrick McManus <pmcmanus@mozilla.com>
- Date: Tue, 25 Feb 2014 12:32:04 -0500
- To: Roberto Peon <grmocg@gmail.com>
- Cc: Cory Benfield <cory@lukasa.co.uk>, HTTP Working Group <ietf-http-wg@w3.org>
Received on Tuesday, 25 February 2014 17:32:32 UTC
fwiw I'm fine with just having http/2 imply a single encoding. On Tue, Feb 25, 2014 at 12:18 PM, Roberto Peon <grmocg@gmail.com> wrote: > True, and the data Jesse links to seems compelling... > -=R > > > On Tue, Feb 25, 2014 at 9:09 AM, Cory Benfield <cory@lukasa.co.uk> wrote: > >> On 25 February 2014 17:02, Roberto Peon <grmocg@gmail.com> wrote: >> > There is zero guarantee that http2 would reliably remove any of that >> logic-- >> > the origin of any particular entity body may be at an HTTP/1 host, which >> > will use 'deflate'. :/ >> >> That's not entirely true. The difference between HTTP/1.1 and HTTP/2.0 >> is that in HTTP/1.1 if I send `Accept-Encoding: identity', the server >> must not return me a compressed response. In HTTP/2.0, however, the >> server may always return a response compressed with gzip or deflate. >> This means all HTTP/2.0 user-agents must allow decompression of gzip >> and deflate encoded responses, because we cannot reliably inform >> upstream that we don't want them. >> >> Jesse and I want to step that back to say that servers may always >> return a response compressed with gzip only: any other compression >> must be explicitly requested. In this sitatuion, if I then send >> `Accept-Encoding: gzip' I'll only ever get gzip back, even if the >> origin of the entity body is a HTTP/1.1 host. This would allow me to >> rip my deflate/zlib code out as I can ensure that it won't be sent to >> me. >> > >
Received on Tuesday, 25 February 2014 17:32:32 UTC