W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

Re: Proposal: Cookie Priorities

From: Mike West <mkwst@google.com>
Date: Mon, 7 Mar 2016 13:24:32 +0100
Message-ID: <CAKXHy=cY+i9mykHDH=MMMXGPTEGu4L6iwtEcXL55YJ_4sx9i_A@mail.gmail.com>
To: Daniel Stenberg <daniel@haxx.se>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, Samuel Huang <huangs@google.com>, Mark Nottingham <mnot@mnot.net>
On Mon, Mar 7, 2016 at 1:09 PM, Daniel Stenberg <daniel@haxx.se> wrote:

> On Mon, 7 Mar 2016, Daniel Stenberg wrote:
> I was actually thinking of the case when 'Priority=High' or 'Priority=Low'
>> is used for an existing cookie, but I think I spoke up a little too early
>> about that since in the case of only one 'Priority' and no (other) cookie
>> name, it should indeed be distinguishable.
> (sorry for replying to myself)
> ...execept for older clients that don't know about these cookie priorities
> of course. For those, they will appear as duplicate cookie names in the
> headers and will most likely cause problems to legacy client-side
> implementations.
> libcurl will treat "Set-Cookie: Priority=Low; favcolor=blue" as a cookie
> named 'Priority' and discard the favcolor part. Reversing the string order
> will make it store 'favcolor' instead. Most surely other implementations
> will act differently.
> Thus, a server needs to know if the client supports Priority cookies
> before it can reliably send them.

I'm confused. Are there clients that process things in the reverse order
from what RFC6265 lays out?

I mean, according to the algorithm I quoted in the previous response,
`Priority=Low; favcolor=blue` _is_ a cookie named `Priority`. Just like
`Max-Age=1; favcolor=blue` is a cookie named `Max-Age` today. I think
that's the way browsers process cookies today. Does `curl` do things

Received on Monday, 7 March 2016 12:25:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:11 UTC