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

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