Re: #305 Header ordering

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/

Received on Friday, 22 November 2013 01:26:13 UTC