Re: #578: Header Table and Static Table Indices Switched

It’s probably not worth the added complexity, but we could add an HPACK control code to swap the tables. A compressor would then be able to pick the best compression for the dataset.

On Sep 30, 2014, at 3:54 AM, RUELLAN Herve <> wrote:

> I did some quick experiments before putting the change in the spec.
> The impact (of putting the dynamic table after the static table) is very small and positive for requests.
> For responses, the impact is very small, positive or negative, for small maximum table size (1-4K). It becomes larger (still being small) and negative for medium table size (8-16K). It is reduced, still negative for larger table size (32K).
> My analysis is that:
> - For small table size, the number of entries is limited, and in both cases, indexes into the dynamic table always fit in 1 octet.
> - For large table size, there are many entries, and in both cases, most indexes into the dynamic table need 2 octets.
> - For medium table size, indexes into the dynamic table use either 1 or 2 octets, with roughly equivalent probability. Therefore, the ordering of the tables has an impact on the compaction.
> My conclusion was, and still is, that the compaction impact was slightly negative, but very small and was more than balanced by the other benefits of putting the dynamic table after the static table.
> Hervé.
>> -----Original Message-----
>> From: Willy Tarreau []
>> Sent: samedi 27 septembre 2014 09:09
>> To: Mark Nottingham
>> Cc: HTTP Working Group
>> Subject: Re: #578: Header Table and Static Table Indices Switched
>> On Fri, Sep 26, 2014 at 04:51:50PM +0100, Mark Nottingham wrote:
>>> <>
>>> This hasn?t seen much discussion on list, and no one seems to have
>> complained about it beyond Jeff.
>>> Does anyone want to argue for changing this, or should we WONTFIX?
>> I think that if there are strong opinions in both directions, it deserves
>> being still studied openly. It's just a matter of encoding, variations are
>> possible (I proposed one some time ago, I don't know if it would have
>> addressed both usages).
>> Why not put numbers on the table. How many different non-standard headers
>> Jeff needs, etc...
>> I'd like that we don't release a protocol which causes significant
>> frustration to every single participant for one reason or another.
>> At least the schedule is not a valid response to tell these people
>> that they'll get a less efficient protocol for their use case, and
>> I'd expect that a short time later someone would have found the
>> best solution, so let's seek it now!
>> Willy

Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat

Received on Tuesday, 30 September 2014 15:57:58 UTC