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
http://matthew.kerwin.net.au/