Re: #305 Header ordering

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?

Cheers,


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