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

Willy,

I actually think that literal without/never indexed should be favoured over
literal indexed or at least on event footing, because by nature the literal
indexed headers are sent only once and then used by index, while the
literal without/never indexed headers are sent literally every time they
are used.

Thus I would think something like:


Indexed Header:
   +---+---+---+---+---+---+---+---+
   | 1 | D |    Index (6+)         |
   +---+---------------------------+

Literal Never Indexed:
   +---+---+---+---+---+---+---+---+
   | 0 | 0 | 0 | D | Index (4+)    |
   +---+---------------------------+

Literal Not Indexed:
   +---+---+---+---+---+---+---+---+
   | 0 | 0 | 1 | D | Index (4+)    |
   +---+---------------------------+

Literal Indexed:
   +---+---+---+---+---+---+---+---+
   | 0 | 1 | 0 | D | Index (4+)    |
   +---+---------------------------+

Max Dynamic Table size change:
   +---+---+---+---+---+---+---+---+
   | 0 | 1 | 1 |  Index (5+)       |
   +---+---------------------------+


I believe that most 62 static slots can easily be filled with values that
will be used.   I'll come up with a suggestion for this tomorrow.

cheers






On 21 October 2014 20:40, Willy Tarreau <w@1wt.eu> wrote:

> On Tue, Oct 21, 2014 at 11:25:05AM +0200, Willy Tarreau wrote:
> > Hi Roberto,
> >
> > On Tue, Oct 21, 2014 at 12:01:19AM -0700, Roberto Peon wrote:
> > > While I prefer the indexing scheme of the previous draft, this proposal
> > > would be better than what is currently drafted.
> >
> > Thanks. Do you know how the following representations are ordered in
> > terms of frequency/probability ?
> >
> >   - Indexed Header Field Representation
> >   - Literal Header Field with Incremental Indexing
> >   - Literal Header Field without Indexing
> >   - Literal Header Field never Indexed
> >
> > I would guess they should appear in the order above, though that's not
> > obvious to me. And I'm still sad at the idea of leaving many encoding
> > values unused (eg: static header values above 16). Thus, we'll typically
> > have 48 possible values out of 256 for the first byte that will never be
> > emitted just for the indexed headers alone, that's a 20% waste, and I
> > really think we can do better without making anything more complex. I
> > just need to ensure I don't propose something stupid.
>
> For example something like this (CCing Greg who also has concerns about
> all this), which supports a single-byte encoding for :
>    - 14 or the 16 static headers with values
>    - all 62 static headers for literals
>    - 62 dynamic headers for literals
>
>    +---+---+----------------------+
>    | 1 | D |  index 6+            |      literal with incremetal indexing
>    +---+---+----------------------+
>
>    +---+---+----------------------+
>    | 0 | 1 |  index 6+            |      indexed dynamic header
>    +---+---+----------------------+
>
>    +---+---+---+---+--------------+
>    | 0 | 0 | 1 | 1 |  index 4+    |      indexed static header
>    +---+---+---+---+--------------+
>
>    +---+---+---+---+--------------+
>    | 0 | 0 | 1 | 0 |  size 4+     |      max dynamic table size change
>    +---+---+---+---+--------------+
>
>    +---+---+---+---+---+----------+
>    | 0 | 0 | 0 | 0 | D | index 3+ |      literal without indexing
>    +---+---+---+---+---+----------+
>
>    +---+---+---+---+---+----------+
>    | 0 | 0 | 0 | 1 | D | index 3+ |      literal never indexed
>    +---+---+---+---+---+----------+
>
> Willy
>
>


-- 
Greg Wilkins <gregw@intalio.com>  @  Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.