Re: #305 Header ordering

[James M Snell <[e-mail]>]

Order is supposed to be insignificant for Link and Prefer. There are others
which could, in theory appear more than once but typically don't.
If-None-Match, If-Match, If-Modified-Since, and If-Unmodified-Since for
example.

The various Auth headers are theoretically order agnostic also... But it
may be safer to preserve order on those.
On Nov 21, 2013 7:36 PM, "Roberto Peon" <[e-mail]> wrote:

> So far, the ones I know about are cookie and setcookie, but mainly because
> those are the ones that I care about.
> -=R
>
>
> On Thu, Nov 21, 2013 at 7:34 PM, James M Snell <[e-mail]> wrote:
>
>> Do we (yet) have a list of all the registered header fields for which
>> order is insignificant?
>>  On Nov 21, 2013 6:39 PM, "Mark Nottingham" <[e-mail]> wrote:
>>
>>> I'm OK with that as long as we have the MUST... unless clause.
>>>
>>>
>>> On 22/11/2013, at 1:29 PM, Roberto Peon <[e-mail]> wrote:
>>>
>>> > As I understand it for either #1 or #3:
>>> > ordering between header values with the same key MUST use
>>> value-concatenation unless the header is known to not care about ordering
>>> (setcookie, etc.).
>>> >
>>> > thus, if we saw the following headers:
>>> >   foo: bar
>>> >   boo: hiss
>>> >   foo: baz
>>> >
>>> > then we'd expect to see foo: bar<delim>baz, and boo: hiss (or boo:
>>> hiss and foo: bar<delim>baz)
>>> >
>>> > If we had:
>>> >   set-cookie: a
>>> >   set-cookie: b
>>> >   foo: bar
>>> >   foo: baz
>>> > then we could expect:
>>> >   set-cookie: b
>>> >   set-cookie: a
>>> >   foo: bar<delim>baz
>>> >
>>> > In other words, ordering is always maintained except when we know it
>>> is safe to ignore.
>>> > -=R
>>> >
>>> >
>>> > On Thu, Nov 21, 2013 at 6:13 PM, Mark Nottingham <[e-mail]>
>>> wrote:
>>> > Well, if by "handle" you mean "anyone who generates or modifies this
>>> header has to understand the special handling", yes...
>>> >
>>> >
>>> > On 22/11/2013, at 12:57 PM, Roberto Peon <[e-mail]> wrote:
>>> >
>>> > > 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 <[e-mail]>
>>> 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" <[e-mail]> 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 <[e-mail]>
>>> 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/
>>> > >
>>> > >
>>> > >
>>> > >
>>> > >
>>> >
>>> > --
>>> > Mark Nottingham   http://www.mnot.net/
>>> >
>>> >
>>> >
>>> >
>>>
>>> --
>>> Mark Nottingham   http://www.mnot.net/
>>>
>>>
>>>
>>>
>