W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: disabling header compression

From: James M Snell <jasnell@gmail.com>
Date: Fri, 13 Dec 2013 10:48:13 -0800
Message-ID: <CABP7RbegFGqnDOeXfU2aMVWbDmvZZpayC2VGjxO9CbvHwtHmfw@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Patrick McManus <pmcmanus@mozilla.com>, Peter Lepeska <bizzbyster@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
Personally, I feel that if we have header compression in the protocol,
it shouldn't be optional. However, it does need to be recognized that
hpack is a brand new mechanism that *does* add significant new
complexity to the protocol, *does* drive up implementation cost, *is*
still largely unproven (saying "trust us our security guys say it's
ok" doesn't really count as "proof"), and has so far only been
implemented by a handful of people who appear to view the use of HTTP
through only very narrow Web browser centric glasses. You cannot sweep
these issues under the rug by shrugging and saying "trust us". Greater
care ought to be taken when adopting such significant new features
(and requirements). It would be interesting to get a gauge of just how
much consensus there is in the WG for adopting hpack as *the* header
compression mechanism for http/2.

On the question of adoption. Let me pose this question: what benefits,
if any, does adoption of HTTP/2 offer to developers of HTTP-based
RESTful APIs? What significant problems does HTTP/2 address that would
justify the implementation costs? (Or is this another, "well they can
just keep using HTTP/1" answer?)

- James


On Fri, Dec 13, 2013 at 10:28 AM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> On 13 December 2013 08:45, Patrick McManus <pmcmanus@mozilla.com> wrote:
>> this is all well trodden territory. HTTP/1 has taught us the folly of
>> optional features. (gzip requests, trailers, etc..)
>>
>> Figure out what is important, define it, and then use it widely. HTTP/2 has
>> done a pretty decent job of that so far with really just one significant
>> exception (and that has a decent reason (flow control)).
>
> I think that there's a simple out for someone who is somehow unwilling
> to implement a decompressor, set the context to zero, and send
> RST_STREAM on stuff that relies on the header table.  That will work
> perfectly well at the cost of a round trip.
>
> I'd rather that those implementations take that hit than every
> implementation.  As Patrick says: game it out and you will see that
> making it optional creates some perverse incentives.
>
> (We made push optional, but that's because we don't have the same
> clear indication that this is valuable.  Even there, the decision
> wasn't certain.)
>
Received on Friday, 13 December 2013 18:49:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:20 UTC