- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Thu, 21 Nov 2013 13:45:32 -0800
- To: Roberto Peon <grmocg@gmail.com>
- Cc: Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>
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