Re: #305 Header ordering

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