Re: #305 Header ordering

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