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

Re: #305 Header ordering

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 26 Nov 2013 13:18:39 +1100
Cc: Martin Thomson <martin.thomson@gmail.com>, Roberto Peon <grmocg@gmail.com>, Tatsuhiro Tsujikawa <tatsuhiro.t@gmail.com>, RUELLAN Herve <Herve.Ruellan@crf.canon.fr>, Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-Id: <E102718F-182E-4229-A436-3737AA2188F4@mnot.net>
To: Jeff Pinner <jpinner@twitter.com>
Given that this is holding up the implementation draft and we have running code for #1, let's stick with it for now. If people feel strongly, we can revisit in the next round.

Make sense?


On 25/11/2013, at 5:39 PM, Jeff Pinner <jpinner@twitter.com> wrote:

> My $.02,
> We've seen '\0' delineation work well and I'm not sure what we gain by changing it to ','
> If an intermediary is going to fold multiple headers because it isn't sure that order is important (especially for headers that do not allow commas) then I would prefer to be able to reconstruct the original as faithfully as possible. For example, let's suppose I get a request with multiple host or content-length headers (yes this does occur). If an intermediary concatenates them, I would prefer it be in a way that lets me re-construct the original input.
> - Jeff
> On Sat, Nov 23, 2013 at 1:47 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 23 November 2013 13:33, Roberto Peon <grmocg@gmail.com> wrote:
> > Wouldn't it be the higher-layers only that need to parse quoted-strings
> > today?  Many loadbalancers need-not parse quoted-strings today, for
> > instance: it is unlikely that any field they care about examining allows
> > quoted-strings...
> >
> > At least in my implementation, the data within the header fields (which
> > might include quoted-strings) are provided by the application which
> > manipluates a headers object. The headers object or lower never needs to
> > parse the field in the outbound path.
> > On the reverse side, the IO library+framer feeds the keys/values into a
> > header object. It doesn't tokenize-- that is left to the application. The
> > framer/headers object never needs to parse the fields in the inbound path.
> That's all true, and exactly the point.
> > Setting that point aside, how would I deal with the following response
> > headers in the #3 proposal?
> >   Set-Cookie: name1=value1; Expires=Wed, 09 Jun 2021 10:18:14
> >   Set-Cookie: name2=value2; Expires=Thu, 10 Jun 2021 10:18:14
> >   Set-Cookie: name3=value3; Expires=Fri, 11 Jun 2021 10:18:14
> I don't know why we keep coming back to the special cases.  But
> anyway, as proposed, we understand order to not be significant for
> Set-Cookie, so this would manifest as multiple name-value pairs, in a
> non-deterministic order.  Cookie is special too, but we actually need
> new rules for Cookie.
> Set-Cookie breaks the general grammar rules for header fields and
> needs to be treated specially.  Neither proposal changes that
> characteristic.
> > Much of the time, there isn't a good reason to want to send these as
> > separate header fields.
> For Set-Cookie, sure, but in terms of cost, it's a question of a few
> bytes difference at most.  I'm not going to get cut up about that.

Mark Nottingham   http://www.mnot.net/
Received on Tuesday, 26 November 2013 02:16:08 UTC

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