Subject: RE: Streaming Header Compression

From: Mike Bishop <[email-masked]>
Date: Mon, 5 Mar 2018 22:23:21 +0000

Thanks for the confirmation.  To summarize, both on-list and in private, I've heard only acceptance about having to have the full set of headers in hand before you can make progress on header compression.  Those comments are purely from the intermediary camp, but there are two things that make me tend to be okay with that:

  *   The intermediary seems, in theory, the party most likely to want to stream headers without committing memory to buffering; if intermediaries say they’re fine, client and server will probably be content as well.
  *   From my former life as a client/server stack owner, I can say that our HPACK library operated on the full header set at once.

If there are people unhappy with this as a design assumption, please speak up quickly.

-----Original Message-----
From: Amos Jeffries [mailto:[email-masked]]
Sent: Wednesday, February 28, 2018 2:15 AM
To: [email-masked]
Subject: Re: Streaming Header Compression

On 28/02/18 17:30, Willy Tarreau wrote:

> On Tue, Feb 27, 2018 at 09:06:32PM +0000, Poul-Henning Kamp wrote:

>> --------

>> In message <[email-masked]<mailto:[email-masked]>>, Mike Bishop writes:

>>> However, that means it's no longer possible to write the beginning

>>> of the frame without having seen and processed the entire header

>>> set.

>> Speaking for the Varnish Cache project:  We are fine with that.

> Same for haproxy, we always process all headers at once.

> And BTW, we have still not implemented support for CONTINUATION frames

> because in the current model they would cause too many problems,

> precisely because we process headers at once. No negative feedback for

> this yet, only h2spec noticed, possibly indicating that they are not

> that much used in field.

> Willy

Squid is the same in this regard. Always wait for the entire header block before any processing beyond parse happens. That is true regardless of HTTP version being used.

Amos