Re: Header Compression Implementation Feedback

Mike,

On Jul 9, 2013, at 9:38 AM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
> No -- there's a single encoding and single decoding table *per connection* and this wouldn't change that.  Each table starts in an initial state with common values in each direction already in the table for convenient back-reference.
> 
> The problem with the initial state as it's currently defined is that it assumes clients only send request headers and servers only send response headers.  In fact, servers also send request headers (PUSH_PROMISE).
> 
> The suggestion is that both directions start with the same initial state.

I'm ok with that part.

However, I think we need to make it clear in the HTTP/2.0 specification that (partial) HEADER frames cannot be interleaved from multiple streams, otherwise the state of the header table will be undefined.  For example, let's say a (multithreaded) client wants to GET /image1.jpg and /image2.png from a server over a single HTTP/2.0 connection using streams 1 and 2, respectively. And let's say that, because of cookies used by the web site, we can't fit all of the request headers into a single HEADER frame.  If the client doesn't serialize the two requests you could end up with:

    1:HEADER  (first request frame on stream 1)
    2:HEADER  (first request frame on stream 2)
    2:HEADER  (second request frame on stream 2)
    1:HEADER  (second request frame on stream 1)
    2:HEADER  (last request frame on stream 2)
    1:HEADER  (last request frame on stream 1)

Since each frame cannot be guaranteed to end at a header boundary, the server reading those HEADER frames has no way to reliably update its copy of the header table used for decoding.  So this means the client needs to serialize HEADER frames (and thus any requests it sends) at a cost of memory and some complexity - whether this cost is greater than per-stream header tables will likely depend on the situation.  It will also limit how quickly a client can issue requests, but that isn't necessarily a bad thing and in most cases the limiting factor is network bandwidth, not CPU...  Oh, and implementations will need to add protection against receiving interleaved HEADER frames from multiple streams...

Similarly, servers have to serialize their outgoing HEADER frames and do the same sort of error checking for incoming HEADER frames.

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.  But personally I think the savings in connection setup time and simultaneous streaming of multiple requests and responses makes this loss in compression acceptable.  It would also simplify the protocol and implementation.


> -----Original Message-----
> From: Michael Sweet [mailto:msweet@apple.com] 
> Sent: Tuesday, July 9, 2013 4:45 AM
> To: Amos Jeffries
> Cc: ietf-http-wg@w3.org
> Subject: Re: Header Compression Implementation Feedback
> 
> If you are suggesting that each endpoint should maintain a single encoding and a single decoding table per stream, I'm +1 on that.
> 
> Sent from my iPad
> 
> On 2013-07-09, at 1:13 AM, Amos Jeffries <squid3@treenet.co.nz> wrote:
> 
>> On 9/07/2013 12:01 p.m., James M Snell wrote:
>>> Another minor item as I've been going through the implementation:
>>> 
>>> 4. Right now, the Header Compression scheme assumes two separate 
>>> pre-filled header tables... one for Request headers, the other for 
>>> response headers. The challenge with this is that it does not account 
>>> for the use of Request Headers within PUSH_PROMISE frames. This is 
>>> minor right now, but it means that PUSH_PROMISE frames will not have 
>>> optimum compression because the request headers will need to be added 
>>> as Literal representations with Indexing. It would be better if we 
>>> just had ONE prefilled table (it would make implementation generally 
>>> easier as well)
>> 
>> +1.
>> 
>> Amos
>> 
> 
> 
> 
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

Received on Tuesday, 9 July 2013 14:28:41 UTC