On 21 October 2014 03:53, Willy Tarreau <w@1wt.eu> 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
- 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.
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.
cheers
--
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.