Re: #305 Header ordering

And to be clear, I mean for #1 to happen only when the semantic-layer cares
about ordering.
If it doesn't (e.g. potentially cookie), then it doesn't collapse the
values into a null-delimited-list-value

-=R


On Thu, Nov 21, 2013 at 12:03 PM, Patrick McManus <mcmanus@ducksong.com>wrote:

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