Re: Static Table Entries

--------
In message <CAH_y2NFqUpFreMM8v4BMZwkuEuasdeCpugqsQBxgw+FkjPc2bA@mail.gmail.com>
, Greg Wilkins writes:

>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.

There is at least one header where raw statistics will mislead us:
Accept-Encoding is subject to stylistic variance with no subtantive
difference in effect.

The three main values I see right now are:

	Accept-Encoding: gzip
	Accept-Encoding: deflate, gzip
	Accept-Encoding: gzip,deflate
	Accept-Encoding: gzip, deflate

To which there is no substantive difference at the end of the day.

Adding one of them to HPACK means that most implementations can
shave 10-ish bytes of the first request without any substantive
change to their codebase.

As author of bikeshed.org I really don't care if it is "gzip,deflate"
or "deflate,gzip" but statistics could tip the scales for just
"gzip" as the most common subset.

So if you have time Greg, I would appreciate numbers for two tests:

A) fold all A-E's containing both "gzip" and "deflate" to the same
   static entry, leave the rest alone.

B) fold all A-E's containing "gzip" to the same static entry, leave
   the rest alone.


-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk@FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

Received on Friday, 8 August 2014 06:11:59 UTC