- From: Greg Wilkins <gregw@intalio.com>
- Date: 2014年10月21日 09:06:50 +1100
- To: Willy Tarreau <w@1wt.eu>
- Cc: Mark Nottingham <mnot@mnot.net>, RUELLAN Herve <Herve.Ruellan@crf.canon.fr>, Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <CAH_y2NFprbTLt5tOrC21hZaHJfvf59B5bgK5-3nmbf8vfKpGOA@mail.gmail.com>
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.
Received on Monday, 20 October 2014 22:07:19 UTC