W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: #305 Header ordering

From: Roberto Peon <grmocg@gmail.com>
Date: Thu, 21 Nov 2013 13:23:33 -0800
Message-ID: <CAP+FsNev5ZsjiCt4ywfarPn8nZ=BraR8RR_SuS-dFh=pZmQe6Q@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Nov 21, 2013 at 12:58 PM, Martin Thomson
<martin.thomson@gmail.com>wrote:

> On 21 November 2013 12:54, Roberto Peon <grmocg@gmail.com> wrote:
> > #3 doesn't work for cookie/setcookie, whereas #1 works for everything.
>
> You already require special code for these two:
> http://http2.github.io/http2-spec/#CompressCookie


That is an optimization for Cookie which can safely be ignored in
implementations.


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


>
>
> > #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.
With #3, to tokenize (but not necessarily interpret), I must parse the
value for quoted strings and split on ','s which are outside those strings.
There are good reasons for one to wish to tokenize and not interpret
(logging, computing differences, etc.).

>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.
-=R
Received on Thursday, 21 November 2013 21:24:01 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:19 UTC