Re: #305 Header ordering

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 <jasnell@gmail.com> 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" <mnot@mnot.net> 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 <grmocg@gmail.com> 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 <mnot@mnot.net> 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 <grmocg@gmail.com> 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 <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/
>> > >
>> > >
>> > >
>> > >
>> > >
>> >
>> > --
>> > Mark Nottingham   http://www.mnot.net/
>> >
>> >
>> >
>> >
>>
>> --
>> Mark Nottingham   http://www.mnot.net/
>>
>>
>>
>>