Re: #305 Header ordering

On 21 November 2013 13:23, Roberto Peon <grmocg@gmail.com> wrote:
>> http://http2.github.io/http2-spec/#CompressCookie
>
> That is an optimization for Cookie which can safely be ignored in
> implementations.

I hope not.  A decoder will need to pay attention.

Regardless, there is still the prohibition regarding multiple Cookie
headers absent this optimization.

>> https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/25/p1-messaging.html#field.order
>
> #1 solves the problem of concatenation for set-cookie since '\0' is always
> disallowed in header values-- with #1, set-cookie is no longer special.

Only if ordering is significant for Set-Cookie.  It's not.  Hence the
"no special desire to invent a new mechanism".

>> > #3 also requires parsing quoted-strings, which is painfully annoying,
>>
>> It does not, it only requires concatenation at the encoder.  Once
>> concatenated, the field is semantically equivalent and therefore
>> doesn't need to be re-split.
>
> True so long as the values are well formed, but at the decoder:
> With #1, to tokenize (but not necessarily interpret), I simply split on
> NULL.

Again not so, because you still have to look for commas in the values
that weren't split across multiple fields.

> From a security perspective, with #1 it is more difficult to get a malformed
> quoted-string to interact with the rest of the header fields.

Malformed header fields generating unexpected results sounds like an
interesting theoretical problem.  It means that you might be able to
sneak something past an intermediary.  It means that you can trigger
something.  I don't find that especially interesting as an attack,
because it exploits an intermediary that isn't doing its job
particularly well.

Received on Thursday, 21 November 2013 21:45:59 UTC