Re: Straw Poll: Restore Header Table and Static Table Indices

Thanks, Willy.

Everyone, please extend the straw poll to include these two options -- who prefers one of them as the solution?

Regards,


On 7 Oct 2014, at 5:16 pm, Willy Tarreau <w@1wt.eu> wrote:

> On Tue, Oct 07, 2014 at 04:54:01PM +1100, Mark Nottingham wrote:
>> Willy, if you have a concrete proposal that you think can can strong
>> consensus, please make it ASAP. Stopping the work to do research on whether a
>> change is necessary isn't appropriate at this point in the work; that train
>> left the station a while ago.
> 
> I have proposed two directions in July and was told it was already too late.
> I'm sorry for not having accurate details anymore in my mind 3 months later,
> but that was the first one :
> 
>       http://article.gmane.org/gmane.ietf.http-wg/23155
> 
> "
> I'm noticing that we need only 4 bits to send any possible static header+value
> (assuming we swap accept-charset and accept-encoding), since all other values
> are empty and will never be used as-is but as litterals.
> 
> So I think that based on your suggestion to split indexing of static and
> dynamic, I'm suspecting we could systematically split indexes between static
> and dynamic in opcodes. Indeed, some index fields are already small (6+ for
> litterals and 4+ for litterals not indexed/never indexed), so having the
> static first will force one extra byte for all dynamic headers. However,
> stealing one bit in unused value ranges could help make that situation
> better. Something along these lines seems possible (please forgive me for
> errors, I'm encoding as I write) :
> 
>  11 XXXXXX => send 6+indexed header from *dynamic* table as-is  (0xC0 reserved)
>  10 01XXXX => send 4+indexed header from *static* table as-is   (0x80 reserved)
> 
>  00 00XXXX => send 4+indexed *dynamic* header without indexing (unchanged)
>  10 00XXXX => send 4+indexed *static* header without indexing
> 
>  10 1XXXXX => send litteral based on *dynamic* header table (0=new name or reserved)
>  01 XXXXXX => send litteral based on *static* header table (0=new name)
> 
> The idea is that even when we have few bits to encode the index, we're not
> forced to add an extra byte to encode the values from the other table, whatever
> table we pick first as first.
> "
> 
> The second one was much simpler and Greg seems to favor it as well :
> 
>       http://article.gmane.org/gmane.ietf.http-wg/23201
> 
> "
> If at least we had the ability to encode both static table and most recent
> dynamic entries with a single index, I would feel better. For example you
> can have another approach :
>  - positive indexes = static table index
>  - negative indexes = - dynamic table index
> 
> You encode (index + 10), so that you can encode up to the last 10 emitted
> fields, and you can encode up to 54 static headers in a single byte (it's
> just a matter of proper sorting but it's already reasonably clean). I think
> you get the idea.
> "
> 
> Greg proposed to run some tests. I really think the second one is *very*
> easy to test in a sane environment, and represents a very small change.
> It ensures that commonly used fields do not need an extra byte, that recently
> indexed headers do not need an extra byte either, and that only old indexed
> headers or rarely used static headers need one. Right now I think that some
> of the static header fields might be less common than a number of the ones
> that are found in the indexed table, precisely because if they're in the
> indexed table, they're being used!
> 
> Regards,
> Willy
> 

--
Mark Nottingham   https://www.mnot.net/

Received on Tuesday, 7 October 2014 06:27:08 UTC