Re: #305 Header ordering

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.

Received on Saturday, 23 November 2013 21:47:42 UTC