#305 Header ordering

Hervé made a few comments on github
(https://github.com/http2/http2-spec/issues/305) that I think needed
to be made here:

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

The actual ordering requirements are very narrow:

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.

Received on Thursday, 21 November 2013 19:13:10 UTC