- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Fri, 18 Apr 2014 19:03:06 -0700
- To: Matthew Kerwin <matthew@kerwin.net.au>
- Cc: Mark Nottingham <mnot@mnot.net>, C.Brunhuber@iaea.org, HTTP Working Group <ietf-http-wg@w3.org>, K.Morgan@iaea.org
- Message-ID: <CABkgnnXd8M7Ya5t+5a9QYq6tMQ0yeboSJ3aYzxxGPRLD8BCVzA@mail.gmail.com>
We had a long discussion regarding gzip and deflate that ended with a conclusion of gzip. I'm not sure that it would be worth re-litigating that decision. I prefer the safer default of 0 if this is an optional feature. But contrary to my earlier message, I am reminded that when it comes to optional features, we have had experience to suggest that they are not a good way to get interoperability. On Apr 18, 2014 4:53 PM, "Matthew Kerwin" <matthew@kerwin.net.au> wrote: > 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/ >
Received on Saturday, 19 April 2014 02:03:35 UTC