Re: Header Table and Static Table Indicies Switched

On 2 August 2014 12:30, Greg Wilkins <gregw@intalio.com> wrote:

> that is just not correct.


Sorry Jeff,  slight correction to my correction.

For indexed fields there are 7 bits available.    These apply to custom
fields whose values do not change every request (eg X-GData-Key:
key=DEVELOPER_KEY), 65 entries are available in the header table that will
encode to 1 byte fields.

Literal fields with indexing have only 6 name bits available, so only 2 1
bytes dynamic field name entries are available.   However, if the field
value is changing every request, then an encoder should not be using the
indexed encoding anyway, as the field will not be used again.   This
encoding should only be used for fields that are expected not to change ie
ones that do not need a name index encoding.   Perhaps this encoding can be
used occasionally for a changing field to get a custom name into the header
table for use with literal fields without indexing, but that is not a high
frequency occurrence.

Literal fields without indexing have only 4 name bits available, so
regardless of the index ordering, many (most?) name indexes are going to be
2 bytes.    But at least the some common names of fields with changing
values  (eg :path) will be 1 byte.  Note that an argument could be made to
reorder the static table so other known fields with changing values (eg
content-length and  if-modified-since) will have index's <16, but I'd like
to see some data first to indicate that any such changes are significant.

I stand by to run the numbers on any data set that anybody can make
available to me.    I do have access to some live header streams, but
nothing that would make any significant usage of custom headers.

regards











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