Re: Proposal: Cookie Priorities

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
differently?

-mike