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

[Willy Tarreau <[e-mail]>]

Hi Greg,

On Tue, Oct 21, 2014 at 09:06:50AM +1100, Greg Wilkins wrote:
> On 21 October 2014 03:53, Willy Tarreau <[e-mail]> wrote:
> 
> > Anyone would please review and/or comment ?
> 
> 
> 
> Willy,
> 
> IF we are changing, then I'm fine with your approach IFF those that are
> advocating bias to dynamic headers are also satisfied with it.
> 
> However, note that I think it needs to be considered together with a review
> of the static table itself.  With your pattern we get :
> 
>    - 62 static 1 byte indexed fields - which are only useful if we have
>    values for most of the first 62 entries in the static table - so we need to
>    add as many valus as possible

Yes I know. Note that it was the case previously as well, which is what
wasted part of the encodable bytes. In the more complex change I proposed
in July, the goal was to only be able to encode static values on 4 bits to
be able to only encode the 16 first static headers which carry a value (and
swap accept-charset and accept-encoding so that we have 16 values first).

>    - For static name, literal value encodings, we only get 6 1 byte indexed
>    fields, so we need to review the table order to ensure that the first 7
>    static entries are most frequently used with dynamic values. Currently that
>    is most definitely not the case.  Also consideration has to be given to the
>    length of the 6 selected fields as if Date encodes to 2 byte index, then
>    you may as well send it huffman encoded and save the 1 byte index for
>    something like last-modified.

Well, till now we could only encode the first 14 ones anyway, and I guess
that the ability to pick the encoding for "status 500" in a literal is much
less common than using accept-encoding or if-modified-since. In my opinion,
the beginning of the static table should only contain *different* header
names. And I still think that inverting the dyn table size update and
literal encodings should be appropriate to save at least one bit for the
latter.

> So currently I'm +0 on this, but if somebody proposed a well tuned static
> table to match then I'd be +1
> 
> If those who are advocating dynamic header support don't dismiss this
> approach, then I'll give a go at proposing such a tuned static table
> tomorrow.

I agree with you. My deep feelings are that we changed the behaviour of
the encoder by removing the ref set and using the static table more than
the dynamic table, and we never reconsidered the impact it had on the way
the opcodes are used, which I suspect has significantly changed. Normally
we should have reworked the encoding based on this to get something more
efficient. But it seems most participants do not want this to happen that
late in the process, while I'm sure we can do much better :-(

Thanks,
Willy