Re: Static Table Entries

Thanks Greg, I opened https://github.com/http2/http2-spec/issues/587 ,
which I will mark as non-blocking.
On Aug 7, 2014 6:10 PM, "Greg Wilkins" <gregw@intalio.com> wrote:

>
>
>
> On 8 August 2014 09:31, Martin Thomson <martin.thomson@gmail.com> wrote:
>
>> On 7 August 2014 15:59,  <K.Morgan@iaea.org> 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 <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.
>