Re: #305 Header ordering

All of the proposals handle any potential nondeterminism amongst header
fields with the same name, so that isn't a problem...

-=R


On Thu, Nov 21, 2013 at 5:43 PM, James M Snell <jasnell@gmail.com> wrote:

> I would note also that implementations can vary on how they handle
> multiple header instances.  For instance, I've seen some impls that only
> pay attention to the first link header in a request while others only see
> the last one.  Nondeterministic ordering could cause bad things to occur.
> On Nov 21, 2013 5:29 PM, "Mark Nottingham" <mnot@mnot.net> wrote:
>
>> So, *any* header that uses the list production *could* be sensitive to
>> ordering.
>>
>> >From a quick look at the registry, besides cookies the following define
>> a meaningful semantic for ordering:
>>
>> A-IM
>> IM
>> Accept-Language (maybe; see our note in p2)
>> Content-Encoding
>> Forwarded
>> Via
>>
>> I can imagine a case where Content-Encoding is applied by an
>> intermediary, but having more than one encoding isn't that common (which
>> might lead to worse bugs, since intermediaries might not be written to
>> check for an existing C-E and fold the headers).
>>
>> Via is interesting, because intermediaries are required to append to it
>> as a message goes through it, and ordering is important for debugging
>> (e.g., loop detection).
>>
>> Presumably X-Forwarded-For and Forwarded suffer from this as well.
>>
>> Another interesting case is one where a header field only allows one
>> value, and an implementation picks the first one (for example) -- e.g.,
>> Host. If ordering after compression isn't deterministic, it may be an
>> attack vector.
>>
>> Cheers,
>>
>>
>>
>> On 22/11/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/
>>
>>
>>
>>
>>