W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: Transfer-codings, mandatory content-coding support and intermediaries

From: Matthew Kerwin <matthew@kerwin.net.au>
Date: Sat, 19 Apr 2014 09:53:34 +1000
Message-ID: <CACweHNDEKrmB0GxbdXe6Rwutyo5zYiY1cOxS2bCmnZWNrE1-kA@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, C.Brunhuber@iaea.org, K.Morgan@iaea.org, Mark Nottingham <mnot@mnot.net>
On 19 April 2014 07:21, Matthew Kerwin <matthew@kerwin.net.au> wrote:

> On Apr 19, 2014 2:41 AM, "Martin Thomson" <martin.thomson@gmail.com>
> wrote:
> >
> > Matthew's proposal is closer to acceptable, though I think that it
> > could (and should) be significantly reduced in complexity.  I think
> > that we could reasonably mandate the use of gzip on a segment by
> > segment basis, which should help with the security concerns (and
> > provide a better excuse for including END_SEGMENT).  Strategic
> > segmentation could be used to separate content.  No alternative
> > compression schemes or negotiation - those lead to interoperability
> > failures.
> >
> The obvious simplification, then, would be to change the setting to
> "accept gzip (yes/no)" (or replace the setting with a MUST support), and
> remove the encoding field from the Data frame.
> This tends back towards the single gzip bit, which is alright, as long as
> it is clear that the compression context applies only to that data frame.

​I've created another branch​ in my fork to track potential words for this
approach (<https://github.com/phluid61/http2-spec/compare/445-gzip>).  If
it's generally acceptable to the wg I'll submit a PR.

Note that I essentially reinstituted the ZLIB compression from #46, with
some more words, and a setting.  It would be trivial to change it from
RFC1950 ZLIB to RFC 1952 GZIP if that's what people prefer.

  Matthew Kerwin
Received on Friday, 18 April 2014 23:54:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC