Re: #305 Header ordering

To be clear - what makes me somewhat comfortable with this approach is that the default is that order is preserved; only if you know that ordering *is* insignificant are you allowed to break it up.

Cheers,


On 22/11/2013, at 2: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/
> 
> 
> 

--
Mark Nottingham   http://www.mnot.net/

Received on Friday, 22 November 2013 03:37:42 UTC