Subject: Re: [http-state] Errata and query on HTTP State Management Mechanism

From: Adam Barth <[email-masked]>
Date: Sun, 3 Apr 2011 16:39:36 -0700

On Sun, Apr 3, 2011 at 4:24 PM, Glyn Geoghegan <[email-masked]> wrote:
> On 30 Mar 2011, at 01:42, Adam Barth wrote:
>> On Sun, Mar 27, 2011 at 10:07 PM, Glyn Geoghegan <[email-masked]> wrote:
>>> On multiple Set-Cookies; 4.1.1 states "Servers SHOULD NOT include more than one Set-Cookie header field in the same response with the same cookie-name.  (See Section 5.2 for how user agents handle this case.)".
>>>
>>> Having read 5.2 I'm still not clear on the suggested behaviour; our research indicates some user agents aggregate the set-cookie directives, some take the first and some take the last; obviously there are notable security implications.
>>>
>>> It is implicit from 5.2 point 11 that, when parsing, each cookie will replace previously stored ones, but I can't see the specific case of multiple same name cookies in a single server response (and regardless it is noted elsewhere that the order of directives is not and should not be considered significant).
>>>
>>> Please can you highlight the paragraphs that disambiguate the situation? (I'm probably missing something obvious, if so, apologies).
>>
>> Correct.  The spec requires the Set-Cookie headers to be processed in
>> the order received.  This is the dominate behavior, although I think
>> one or two user agents process them in the reverse order.  Excitingly
>> nutty things happen if you have two cookies with the same name and
>> different paths.
>
> Indeed!  So is there any plan/way to formalise this to remove the ambiguity and resulting potential security issues?

The document already requires a unambiguous behavior in this regard.
I have no doubt we could make editorial improvements to make those
requirements clearer.  We should keep that in mind for next time we
revisit the specification of this protocol.

> While the server SHOULD NOT set multiple same name/path headers, as you've also observed they often do and the resulting user-agent actions aren't predictable.

In the meantime, I encourage you to modify user agents to align to the
dominate behavior (i.e., the one in the spec).  That's of most
immediate help to folks using the protocol and will make our lives
easier in the future if/when we update the specification for the
protocol.

Thanks,
Adam

---

From: Glyn Geoghegan <[email-masked]>
Date: Mon, 4 Apr 2011 09:24:13 +1000

G
--

----------------------------------------------------------------------
CONFIDENTIALITY:  This e-mail and any files transmitted with it are
confidential and intended solely for the use of the recipient(s) only.
Any review, retransmission, dissemination or other use of, or taking
any action in reliance upon this information by persons or entities
other than the intended recipient(s) is prohibited.  If you have
received this e-mail in error please notify the sender immediately
and destroy the material whether stored on a computer or otherwise.
----------------------------------------------------------------------
DISCLAIMER:  Any views or opinions presented within this e-mail are
solely those of the author and do not necessarily represent those
of Corsaire Limited, unless otherwise specifically stated.
----------------------------------------------------------------------
Corsaire Limited, head office: Unit 2 Grosvenor Court, Hipley Street,
Old Woking, Surrey GU22 9LL. Telephone: +44 (0)1483-746700.
Registered in England No. 3338312. Registered office: Portland House,
Park Street, Bagshot, Surrey GU19 5PG.