Re: #305 Header ordering

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