RE: Header Compression Implementation Feedback

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.

-----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
>

Received on Tuesday, 9 July 2013 13:40:34 UTC