Re: #305 Header ordering

based on running code, #1 is good


On Thu, Nov 21, 2013 at 2:49 PM, Roberto Peon <grmocg@gmail.com> wrote:

> #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.
>>
>>
>