- From: James M Snell <jasnell@gmail.com>
- Date: Tue, 9 Jul 2013 08:50:19 -0700
- 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