W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: #305 Header ordering

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 22 Nov 2013 19:11:41 +1100
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-Id: <0CE4D6FA-4A80-4039-B632-0AB55B97DAC9@mnot.net>
To: Martin Thomson <martin.thomson@gmail.com>, Jeff Pinner <jpinner@twitter.com>
IIRC in Seattle we talked about cases (esp. back ends) where preserving the difference between comma delimitation and a new header line was important when going 1.1<->2.0. IIRC Jeff felt strongly about this… (?)

On 22 Nov 2013, at 6:12 am, Martin Thomson <martin.thomson@gmail.com> wrote:

> Hervé made a few comments on github
> (https://github.com/http2/http2-spec/issues/305) that I think needed
> to be made here:
> Hervé:
> There are at least to ways of providing ordering between headers:
> * Using null-separated list of values, and mandating that the
> ordering of the values in these lists must be preserved.
> * Relying on the emission order. The only difficulty here is that the
> ordering of the headers in the reference set can not be chosen by the
> sending application. However tricks (like double indexed
> representation) can be used by the encoder to enforce an order.
> If we are only targeting the ordering of cookies, then using
> null-separated list of values is sufficient.
> * It stays in the main HTTP/2.0 spec, therefore is not dependent of
> the header compression layer.
> * It allows removing from HPACK the emission ordering constraints.
> <<<
> On the first, this contradicts a previous decision.  Cookies need to
> be decomposed into pieces to get compression efficiency
> (https://github.com/http2/http2-spec/issues/292).
> The actual ordering requirements are very narrow:
> http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-25#section-3.2.2
> I see three options:
> 1. A null-delimiter and collapsing all header field instances for the
> same name into the same value.
> 2. A requirement on the compression to preserve order (for fields with
> the same name).  The best part about this is that it isn't that
> difficult to achieve, because the only non-deterministic part of the
> decoder is the reference set emission.  Make that deterministic (emit
> in same order as last time; emit from highest table index to lowest)
> and we avoid the need for null-delimited sequences altogether.
> An encoder then follows an algorithm where it forces emission of
> header fields as they appear.  Items can be left in the reference set
> if they are in the same order as last time (which requires a little
> bit of accounting to implement, or you can double-emit the index and
> avoid the accounting entirely).
> 3. Avoid the problem altogether and recommend the use of commas for
> preserving order.  The only cases where this doesn't work is for
> Cookie and Set-Cookie.  For those, I know it might sound a little
> risky for some, but losing ordering might not be a bad thing there,
> despite what 6265 says.

Mark Nottingham   http://www.mnot.net/
Received on Friday, 22 November 2013 08:12:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:20 UTC