- From: Michael Sweet <msweet@apple.com>
- Date: Tue, 09 Jul 2013 11:50:24 -0400
- To: Martin Thomson <martin.thomson@gmail.com>
- Cc: Mike Bishop <Michael.Bishop@microsoft.com>, Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Martin, On 2013-07-09, at 11: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. Perhaps my confusion comes from the beginning of section 6.2: 6.2. HEADERS The HEADERS frame (type=0x1) carries name-value pairs. The HEADERS is used to open a stream (Section 5.1). Any number of HEADERS frames can be sent on an existing stream at any time. I was definitely under the impression that you could do multiple (sequential) requests over a single stream, with the END_STREAM flag signaling the close of the stream. _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair
Received on Tuesday, 9 July 2013 15:51:06 UTC