Re: #305 Header ordering

On Thu, Nov 21, 2013 at 1:45 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

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

The cookie optimization can be safely ignored by an encoder, but never a
decoder, true.


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

The application should see a single cookie, I think you mean (we don't
otherwise care how it transmitted).


> >>
> 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".
>

We need a mechanism one way or another for fields where order might matter.

I'm saying that the mechanism in #1 can be used to transmit the multiple
Set-Cookie headers in the response instead of potentially sending a bunch
of opcodes one at a time. This can end up being more efficient than
sticking it into the compression context (e.g. when not using an indexed
mode).
The fact that we don't care about the order for a particular field means
that it can't hurt if we do specify an order for that field. Any such order
can simply be ignored after detokenizing for fields that don't care about
ordering.


> >> > #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.
>

I don't need to do that for SetCookie today-- each one is its own header.


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

It would/could affect any recipient where the sender allowed a value to be
stuck into a header without doing adequate checking for correctness.
I agree it isn't something to be overly concerned about.


We've already implemented '\0' delimiting! It hasn't yet caused any issue
that I know of.

-=R