W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2014

Re: Static Table Entries

From: Simpson, Robby (GE Energy Management) <robby.simpson@ge.com>
Date: Fri, 8 Aug 2014 19:46:45 +0000
To: Martin Thomson <martin.thomson@gmail.com>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <D00A9F19.38FE8%Robby.Simpson@GE.com>
On 8/7/14, 4:26 PM, "Martin Thomson" <martin.thomson@gmail.com> wrote:


>On 7 August 2014 13:11, Simpson, Robby (GE Energy Management)
><robby.simpson@ge.com> wrote:
>> Looking at the current entries, I believe it would be useful to add at
>> least the following:
>> - :method PUT
>> - :method DELETE
>> - :method HEAD
>> - :status 201
>
>The values we have there are based on a frequency analysis provided by
>Akamai.  The methods and status codes that we have account for some
>ridiculously large proportion of requests.  And note that every entry
>makes the header table larger, which increases the number of bytes
>needed to reference the header table.

Understood.  The suggested entries above are from a different perspective.
 While I concede that Web is the primary use case, and that I'm certain
Akamai has provided great data for that, the above suggestions come from
my experience in the IoT space.

These actually account for a great deal of the traffic there, and often
headers are a large part of the overall message payload.

>> And perhaps:
>> - :method
>> - :path (even this would save ~4 bytes IIUC, vs. the first occurrence)
>> - :status
>
>Bare values aren't necessary.  You can reference an entry with a value
>and provide a different value.

That's great.  My apologies - I did not catch that from my read of hpack.
Then I would certainly agree with others that having values for all of the
entries is a no-brainer.

>> I find it odd that common content types are not in the static table
>
>See above.  There just isn't enough commonality in these header fields
>to justify adding the extra entries.  We just don't have enough good
>data.  And getting good data is only a small part of the problem;
>we're basically done here, so changes like this require overpowering
>justification.

Understood.  My fear is that the static table is immutable going forward,
so we may have to live with it for a long time.

One other issue I've found in the static table entries:  I've noted that
they are all in alphabetical order, which makes searching much easier.
However, there appears to be one outlier -- "accept."  Since "/" comes
before "/index.html", shouldn't "accept" come before "accept-charset",
etc.?
Received on Friday, 8 August 2014 19:47:11 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 30 March 2016 09:57:10 UTC