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

Re: Header Compression Implementation Feedback

From: James M Snell <jasnell@gmail.com>
Date: Tue, 9 Jul 2013 08:50:19 -0700
Message-ID: <CABP7Rbf+WbiQ6n1+metu2jktj9qB6Abysx7-vMS1c6zjmL6WLg@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Michael Sweet <msweet@apple.com>, Mike Bishop <Michael.Bishop@microsoft.com>, Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Tue, Jul 9, 2013 at 8:17 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 9 July 2013 07:28, Michael Sweet <msweet@apple.com> wrote:
>> If instead we use a per-stream header table then we avoid this complexity but end up with less effective compression, particularly if clients and servers do not reuse streams for multiple requests.
>
> Perhaps there is a misapprehension about how this works.  The draft
> says: "An HTTP request/response exchange fully consumes a single
> stream."
>
> That means that:
>  1. You only get one set of headers on every stream in each direction,
> with the exception of push promises, of which there can be any number
> on the same stream as a response.
>  2. As a result, unless you have lots of push promises, per-stream
> header compression will net almost zero compression gain.
>

Well, header compression is at the framing layer, which could have any
number of HEADERS frames and PUSH_PROMISE frames sent, but the point
stands... per-stream header tables would be a very bad idea... (in my
opinion it's bad enough that we need to have one for each direction).
Received on Tuesday, 9 July 2013 15:51:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC