Re: Static Table Entries

[Greg Wilkins <[e-mail]>]

On 8 August 2014 09:31, Martin Thomson <[e-mail]> wrote:

> On 7 August 2014 15:59,  <[e-mail]> wrote:
> > I think we should at least keep a list (wiki page) of these micro
> optimizations so that we could discuss further if the draft doesn't make it
> out if last call for some reason.
>
> Last call doesn't mean that we are forbidden from discussing changes.
> It's not special in that regard.  It's primarily time that causes the
> threshold to be raised.  If implementations have to go back and make
> other changes, then it definitely would be easier to throw in a few
> small optimizations like this, even larger ones (like reworking the
> HPACK opcode sequences), but I predict that any change, no matter how
> small, will get some resistance.
>



I did some rough frequency analysis on the test data and came up with extra
values for:

"accept-language","en-US,en;q=0.5"
"accept-ranges","bytes"
"accept","image/png,image/*;q=0.8,*/*;q=0.5"
"age","0"
"allow","GET"
"cache-control","no-cache"
"content-disposition","attachment"
"content-encoding","gzip"
"content-language","en-US"
"content-length","0"
"content-type","image/jpeg"
"vary","Accept-Encoding"

Adding these values improved compression of the test data by 1.1%

However, removing anything that looks like linguistic imperialism and
making a few more neutral choices gives:

"accept-ranges","bytes"
"accept","*/*"
"age","0"
"allow","GET"
"cache-control","no-cache"
"content-disposition","attachment"
"content-encoding","gzip"
"content-length","0"
"content-type","application/x-javascript"
"vary","Accept-Encoding"

This still achieved 0.9% saving.

However I'd like to see some rigour applied to selecting the most frequent
value to apply, and I don't think the test data is large enough nor
representative enough for this.


So I think this is a good change to make  IFF we are breaking the protocol
for another reason, but it's probably not good enough to justify breaking
on it's own (unless someone can produce hard numbers).

So I'm happy to put this one on a list of breaking changes to make if we
are going to make breaking changes.


cheers









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