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

Re: HPACK opcode bit patterns

From: Greg Wilkins <gregw@intalio.com>
Date: Thu, 7 Aug 2014 08:22:14 +1000
Message-ID: <CAH_y2NHLz6GPPFxa2k1Ag=pWQwZbiEvLDkVbamAUA_VqX5kMYQ@mail.gmail.com>
To: Michael Sweet <msweet@apple.com>
Cc: Jason Greene <jason.greene@redhat.com>, David Krauss <potswa@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 7 August 2014 01:12, Michael Sweet <msweet@apple.com> wrote:

> With my current experience in implementing HTTP/2, I'm currently encoding
> the following headers using one of the non-indexed forms:
>
> - Authorization (never indexed)
> - Content-Length (without indexing)
> - Content-Location (without indexing)
> - Content-MD5 (without indexing)
> - Content-Range (without indexing)
> - Content-Version (without indexing)
> - Date (without indexing)
> - If-Modified-Since (without indexing)
> - If-Unmodified-Since (without indexing)
> - Last-Modified (without indexing)
> - Link (without indexing)
> - Location (without indexing)
> - Range (without indexing)
> - Retry-After (without indexing)
>
> My general rule for "without indexing" is "anything that will likely
> change between requests/responses", which includes date/time fields,
> hashes, locations, ranges, byte counts, etc.  And of course authorization
> data is "never indexed".
>

Jetty pretty much has the same.   However I'm thinking that we will index
Date as we often see batches of messages sent within the same second.

We are also currently never indexing set-cookie, but I admit to be confused
about the need to do this or if it can just be without index?

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.
Received on Wednesday, 6 August 2014 22:22:42 UTC

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