Re: disabling header compression

Patrick said: "Now clients send a burst of 30 parallel requests in the
same cwnd on the first rtt (the real value of the compression)"

I agree. This is actually the most compelling reason to do header
compression -- to send as many GET requests as possible on a single
cwnd. And my job is to make the web faster so I'm all about
performance gains, which this certainly is, but since we're designing
a protocol it does feel a little hackish. It reminds me of domain
sharding, which was a great idea until everyone realized that it
increased the impact of TCP slow start. I wonder if instead we should
be pushing for increasing initcwnd on more than just server operating
systems. Or using multiple TCP connections for our HTTP/2 sessions. Or
making the protocol itself leaner in the case when multiple GETs are
issued to the same web server. Anyway, adding header compression
primarily for what is essentially one narrow (and possibly short term)
case of a bad fit between HTTP and TCP feels like a potential detour,
especially since trading cpu for lower bandwidth usage makes less and
less sense as bandwidth gets cheaper and more abundant.

On an unrelated note I appreciate that adding enable/disable to
SETTINGS is complicated by the fact that the browser sends GETs before
receiving the server's SETTINGS frame and I would not want the browser
to wait. After thinking about it it seems like what Roberto suggested
is basically the best we can do if it is not part of protocol
negotiation and we don't want the browser to wait:

"If you don't want to handle compression you:
1) Send a SETTINGS frame requesting that the receive side-context be
sized to zero.
2) RST all streams that would store state in the compression context
until you receive the acknowledgement that this has occurred from the
remote side.
3) Proceed normally to handle stuff with zero context size."

I'm fine with this approach, though it's a little obscure. It'd be
nice if there was simply a "don't compress" button, but I get why that
is now.



On Fri, Dec 13, 2013 at 1:48 PM, James M Snell <> wrote:
> 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
> <> wrote:
>> On 13 December 2013 08:45, Patrick McManus <> 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 20:45:19 UTC