Re: #305 Header ordering

#1 works today (and is my preference).
If we simply specify that  a null in a value is to be interpreted as
multiple key-values (with the same key), then we allow everything #3 does.

#2 makes it very difficult to use HTTP2's framing layer for non-HTTP
transport. That sucks. It also still requires either #1, #3, or machinery
in the HTTP<->Encoder interface to force things to be emitted in the order
desired by referencing items multiple times.

#3 seems more finicky than #1, with no real advantages.

#1 is my strong preference.
-=R


On Thu, Nov 21, 2013 at 11: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.
>
>