Re: #305 Header ordering

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