610218 - Quotes in "path" for Set-Cookie are taken literally

Status: RESOLVED FIXED

(Core :: Networking: Cookies, defect)

Description

[Daniel Hahler]

User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101106 Firefox/4.0b8pre
Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101106 Firefox/4.0b8pre

A header like
  Set-Cookie: foo=bar;path="/";
will set the cookie for path '"/"' (using the quotes).

This leads to cookies not being sent back.

Reproducible: Always

Steps to Reproduce:
1. Go to http://hahler.de/tmp/test-cookie.php
2. Reload the page

Actual Results:  
No cookie "testc1" is being sent back from Firefox on reload.

Expected Results:  
"testc1" should have been sent.

Looking into the cookie dialog you'll see that the path is '"/"' for testc1.

Other browsers like Chromium and Konqueror are OK.

http://www.ietf.org/rfc/rfc2109.txt says:

   Note that the Expires date format contains embedded spaces, and that
   "old" cookies did not have quotes around values.  Clients that
   implement to this specification should be aware of "old" cookies and
   Expires.

This is all I could find about "quotes" in there.

Comment 1

[Daniel Hahler]

Here is the PHP test script for reference:

<?php
error_reporting(E_ALL); ini_set('display_errors', 1);

$c1 = isset($_COOKIE['testc1']) ? $_COOKIE['testc1'] : NULL;
$c2 = isset($_COOKIE['testc2']) ? $_COOKIE['testc2'] : NULL;

$header1 = 'Set-Cookie: testc1='.($c1+1).';path="/";';                    
$header2 = 'Set-Cookie: testc2='.($c2+1).';path=/;';

header($header1);
header($header2);

echo "<pre>\n";
echo "testc1: ".$c1."\n";
echo "testc1: ".$c2."\n";
echo "Sent headers:\n";
var_dump($header1);
var_dump($header2);
echo "\n</pre>\n";

Comment 2

[Daniel Hahler]

Here is a bug about an application being affected (Freenet FProxy): https://bugs.freenetproject.org/view.php?id=4224

Comment 3

[Boris Zbarsky [:bzbarsky]]

From RFC 2109, the relevant BNF is:

     value           =       word
     word            =       token | quoted-string
     cookie-av       =       "Comment" "=" value
                   |       "Domain" "=" value
                   |       "Max-Age" "=" value
                   |       "Path" "=" value
                   |       "Secure"
                   |       "Version" "=" 1*DIGIT

so it seems pretty clear that the path can be a quoted-string.  quoted-string is defined by reference to RFC 2068:

          quoted-string  = ( <"> *(qdtext) <"> )
          qdtext         = <any TEXT except <">>
          TEXT           = <any OCTET except CTLs,
                           but including LWS>

(details of what CTLs and LWS happen to be aren't relevant here).

Looks like nsCookieService::GetTokenValue should be handling quoted-string values.

Comment 4

[[e-mail]]

Perhaps. Adam, do you have any data on this?

Comment 5

[Adam Barth]

I don't think the other browsers treat " as a special character here.  What's going on is that Firefox isn't rejecting bogus Path attributes.  The new spec says to ignore path attributes that don't start with a / character.  That will cause the cookie to get the default path, which will probably fix the site if it works in other browsers.

Comment 6

[Daniel Hahler]

Adam, what is "the new spec" you are referring to?
Don't you think accepting quoted strings may still make sense, since it worked before (and is supposed to work according to the BNF Boris quoted)?

I would just say that FF4 has regressed in removing quotes from the path attribute, and therefore only treating it as (multi-word-)"token", but not "quoted-string" anymore.

Comment 7

[Adam Barth]

(In reply to comment #6)
> Adam, what is "the new spec" you are referring to?

http://tools.ietf.org/html/draft-ietf-httpstate-cookie-23

> Don't you think accepting quoted strings may still make sense, since it worked
> before (and is supposed to work according to the BNF Boris quoted)?

Nope.  The correct behavior is to do what I recommended in Comment #5, which is what every other browser does, AFAIK.

> I would just say that FF4 has regressed in removing quotes from the path
> attribute, and therefore only treating it as (multi-word-)"token", but not
> "quoted-string" anymore.

I didn't quite follow.  I recommend following draft-ietf-httpstate-cookie-23, which has obsoleted both RFC 2109 and 2965.

Comment 8

[xor]

Hi. I am the developer of said Freenet project cookie generator/parser.
I would like to say the following w.r.t. Comment #5 and Comment #7:

I wrote our cookie generator to be compatible with
http://www.ietf.org/rfc/rfc2965.txt

Now even though there is a newer RFC which you pointed out, I do not understand how this one can suddenly render quotes to be treated as non special characters:
RFC 2965 specifies quoting as to be treated as quoting, not as part of the value.
It even shows many examples with Path="Value".
The format has always contained a Version=Number pair so cookies which are valid in terms of 2965 cannot suddenly become invalid with a parser which supports the new RFC "draft-ietf-httpstate-cookie-23" because the Version allows to identify that the cookies were generated for 2965.


I would consider the latest RFC which you mentioned in Comment #7 as absolutely braindead if it REALLY says "to ignore path attributes that don't start with a / character. " even for 2965 cookies.

So I think you are just misinterpreting the new RFC.
The following interpretations would make sense:
- "Path which does not start with / must be ignored IF the Version attribute is set to the version of the new RFC"
- "Path which does not start with / must be ignored. The quote character with which the path starts must not be taken into account, it is valid".

An invalid interpretation is IMHO:
- "Cookies which are valid in terms of 2965 are not valid in terms of the new RFC anymore, even though they contain a Version attribute"

So please repair the Firefox to parse quotes properly again. I do not want to modify my beautiful valid 2965 cookie generator just because your browser fails to conform to a 10 year old RFC :-)

Comment 9

[xor]

Also the argument 'I don't think the other browsers treat " as a special character here.' is wrong in two ways:
- Just because other browsers are not standard compliant does not change the standard.
- Chrome 10.0.648.204 and Opera 11.01 *DO* work with the said cookies.

Comment 10

[xor]

Checking the RFC you mentioned revealed another issue: It specifies behavior of Set-Cookie, not Set-Cookie2.

http://tools.ietf.org/html/draft-ietf-httpstate-cookie-23
"This document defines the HTTP Cookie and Set-Cookie header fields."

Therefore, RFC 2965 is the only RFC which should be taken into consideration when fixing the issue for Set-Cookie2 cookies. And 2965 specifies cookies with quoted paths as examples of valid cookies as said.

Comment 11

[Adam Barth]

> I wrote our cookie generator to be compatible with
> http://www.ietf.org/rfc/rfc2965.txt

That was you first mistake.  :)

> Now even though there is a newer RFC which you pointed out, I do not understand
> how this one can suddenly render quotes to be treated as non special
> characters:

No major browser (besides Opera) ever implemented RFC 2965.  It's a fail spec and has been obsoleted and moved to historic.

> I would consider the latest RFC which you mentioned in Comment #7 as absolutely
> braindead if it REALLY says "to ignore path attributes that don't start with a
> / character. " even for 2965 cookies.

That's not the consensus of the Internet community as expressed in the IETF.

> So I think you are just misinterpreting the new RFC.

I wrote the new RFC.  I doubt I'm misinterpreting it.

> Checking the RFC you mentioned revealed another issue: It specifies behavior of
> Set-Cookie, not Set-Cookie2.
> 
> http://tools.ietf.org/html/draft-ietf-httpstate-cookie-23
> "This document defines the HTTP Cookie and Set-Cookie header fields."
> 
> Therefore, RFC 2965 is the only RFC which should be taken into consideration
> when fixing the issue for Set-Cookie2 cookies. And 2965 specifies cookies with
> quoted paths as examples of valid cookies as said.

Firefox doesn't support Set-Cookie2.  In fact, almost no one supports Set-Cookie2.  This bug is about Set-Cookie.

I'm sorry RFC 2965 has caused you pain and misery.  That's been it's main function in life.  Let's all breath a sigh of relief that it won't cause future folks more pain and misery now that it's dead and buried.

Comment 12

[xor]

Ok so Firefox does not support Set-Cookie2.
In fact I have checked my code and it falls back to RFC 2965 because of that, there even is a TODO in the code which states that Firefox does not support 2965.

Then RFC 2109 is the one which clients should be conform to, as your "draft-ietf-httpstate-cookie-23" is from March this year and still a draft.

RFC 2109 also states that quoting values in key value pairs is valid.

It also states:
   Version=version
      Required.  The Version attribute, a decimal integer, identifies to
      which version of the state management specification the cookie
      conforms.  For this specification, Version=1 applies.

so its absolutely possible to detect that a cookie is conform to 2109 or 2965.

Yet Firefox misinterprets cookies which are 2109-conform as cookies which were created to the rules of your shiny new draft and misinterprets the "-characters as the draft has different rules for them than 2109.

Now the question is, why do we even HAVE to discuss this?
The protocol for Set-Cookie cookies is clearly specified in RFC 2109. Cookies which follow the 2109 rules identify themselves by setting Version.
You interpret them as cookies of a DIFFERENT specification than 2109.
You are doing it wrong.

What is the big deal here? Please fix this.

Comment 13

[xor]

Correction of Comment #12: Of course my code falls back to 2109, not 2965

Comment 14

[Adam Barth]

> Then RFC 2109 is the one which clients should be conform to, as your
> "draft-ietf-httpstate-cookie-23" is from March this year and still a draft.

draft-ietf-httpstate-cookie-23 is no longer a draft.  It's been approved for publication as an RFC.  We're just waiting for the RFC editor to assign it a number.  In particular, it's listed as the controlling document for the Cookie and Set-Cookie header fields:

http://www.iana.org/assignments/message-headers/perm-headers.html

> RFC 2109 also states that quoting values in key value pairs is valid.
> 
> It also states:
>    Version=version
>       Required.  The Version attribute, a decimal integer, identifies to
>       which version of the state management specification the cookie
>       conforms.  For this specification, Version=1 applies.
> 
> so its absolutely possible to detect that a cookie is conform to 2109 or 2965.

No implemented Version.  RFC 2109 is closer to reality than 2965, but both are sorely mistaken in a number of areas, which is why we wrote a new spec that agrees with reality.

> Now the question is, why do we even HAVE to discuss this?
> The protocol for Set-Cookie cookies is clearly specified in RFC 2109.

Nope.  RFC 2109 has been obsolete for years.  In fact, the protocol for Set-Cookie cookies is specified by draft-ietf-httpstate-cookie-23, as you can plainly see from the IANA registry linked above.

> What is the big deal here? Please fix this.

If you'd like to change the Set-Cookie protocol to have a different behavior, the correct forum for that discussion is the IETF, not this bug.  However, I suspect you'll have difficulty convincing the Internet community of your point of view.

Comment 15

[xor]

> > Then RFC 2109 is the one which clients should be conform to, as your
> > "draft-ietf-httpstate-cookie-23" is from March this year and still a draft.
> 
> draft-ietf-httpstate-cookie-23 is no longer a draft.  It's been approved for
> publication as an RFC.  We're just waiting for the RFC editor to assign it a
> number.  In particular, it's listed as the controlling document for the Cookie
> and Set-Cookie header fields:

No matter what it is labeled, if it breaks parsing of Cookies which were correct under previous standards it is a design failure.

I would like to go even further and say that the design seems to completely ignore basic computer science. Computers are language processors and for them to work correctly it is absolutely necessary to have texts of languages to clearly specify which language they are from. If a new language design overlaps with an other, older language which has different semantics, which RFC 2109 and the draft do, it is crucial for the new language to contain a different identification string, which the draft does NOT. 

> http://www.iana.org/assignments/message-headers/perm-headers.html
> 
> > RFC 2109 also states that quoting values in key value pairs is valid.
> > 
> > It also states:
> >    Version=version
> >       Required.  The Version attribute, a decimal integer, identifies to
> >       which version of the state management specification the cookie
> >       conforms.  For this specification, Version=1 applies.
> > 
> > so its absolutely possible to detect that a cookie is conform to 2109 or 2965.
> 
> No implemented Version. 

What do you mean by that?

> > Now the question is, why do we even HAVE to discuss this?
> > The protocol for Set-Cookie cookies is clearly specified in RFC 2109.
> 
> Nope.  RFC 2109 has been obsolete for years.

The fact that it is obsolete does not mean that you should suddenly change existing programs (Firefox) to interpret output which servers which run RFC 2109 and declare as RFC2109 (by "Version=") as the output of a different RFC which is your draft, does it?

There is all sorts of obsolete protocols, file formats, etc. on the Internet and just because a newer format exists does not mean that clients should suddenly stop supporting the old format.

> > What is the big deal here? Please fix this.
> 
> If you'd like to change the Set-Cookie protocol to have a different behavior,
> the correct forum for that discussion is the IETF, not this bug. 

No, this bug is the correct place.
Firefox interprets Set-Cookie headers which are of RFC 2109 language as headers of the draft-23 language. Which they are clearly not, they specify Version=1

I have also sent a mail to IETF which requests that draft-23 must receive a mandatory version attribute.

> However, I
> suspect you'll have difficulty convincing the Internet community of your point
> of view.

<irony>Yes it will be really difficult to convince people that a packet of network protocol version X should not be interpreted to be one of version Y</irony>

Comment 16

[Adam Barth]

Attachment: Patch to fix handling of bogus cookie paths

Here's a patch that fixes the issue discussed in Comment #5.  The spec says:

[[
   If the attribute-value is empty or if the first character of the
   attribute-value is not %x2F ("/"):

      Let cookie-path be the default-path.

   Otherwise:

      Let cookie-path be the attribute-value.
]]

http://tools.ietf.org/html/draft-ietf-httpstate-cookie-23#section-5.2.4

We were missing the "/" check, which is why this site works in other browsers but not in Firefox.  The attached patch add that check and a test for the handling of bogus Path attributes.

Comment 17

[xor]

Your patch is incompatible to RFC 2109 for which the said cookies were created and and introduces possible security vulnerabilities.

Vulnerability: If you ignore the specified path attribute in the cookie and default to "/" then the browser will send back the cookie to ALL scripts which run on the server on the given domain. So the original creator script of the cookie wanted to restrict the path to ensure that not all inhabitants of "/" get to see the contents of the cookie and you reveal the contents to ALL inhabitants of "/"

Wrongness: As described in the discussion above you are misinterpreting cookies which are of RFC2109 language as if they were designed for your draft-23. It seems like you decided to quit the discussion due to lack of arguments on your side which is disappointing.

Comment 18

[Shawn Wilsher :sdwilsh]

(In reply to comment #14)
> draft-ietf-httpstate-cookie-23 is no longer a draft.  It's been approved for
> publication as an RFC.  We're just waiting for the RFC editor to assign it a
> number.  In particular, it's listed as the controlling document for the Cookie
> and Set-Cookie header fields:
Do you know when it might be assigned a number?

(In reply to comment #17)
> Your patch is incompatible to RFC 2109 for which the said cookies were created
> and and introduces possible security vulnerabilities.
As mentioned previously, RFC 2109 was obsoleted (in October 2000) by RFC 2965, which is soon to be obsoleted (as I understand it) by the draft Adam has mentioned.  The web isn't a static place, and standards do change.

Comment 19

[Adam Barth]

(In reply to comment #18)
> Do you know when it might be assigned a number?

Once it gets to the top of this queue:

http://www.rfc-editor.org/queue.html

Comment 20

[xor]

(In reply to comment #18)
> (In reply to comment #17)
> 
> > Your patch is incompatible to RFC 2109 for which the said cookies were
> > created and and introduces possible security vulnerabilities.
> 
> As mentioned previously, RFC 2109 was obsoleted (in October 2000) by RFC
> 2965, which is soon to be obsoleted (as I understand it) by the draft Adam
> has mentioned.  The web isn't a static place, and standards do change.

RFC 2965 does NOT specify a Set-Cookie header, it only specifies Set-Cookie2, so RFC 2109 is still valid for the "Set-Cookie" header of which this bug is about.
(RFC2965: "This document specifies a way to create a stateful session with
   Hypertext Transfer Protocol (HTTP) requests and responses.  It
   describes three new headers, Cookie, Cookie2, and Set-Cookie2, which
   carry state information between participating origin servers and user
   agents.  ")

So the state of the issue is the following: We have a specification of Set-Cookie called RFC2109 which was the only specification of it for 14 years. Now suddenly someone specifies a DIFFERENT behavior of Set-Cookie which is INCOMPATIBLE as the said draft-23 and tries to make client authors implement the incomparability to servers which follow a 14-year-established standard.

This is a shame IMHO. You cannot suddenly change the semantics of a protocol after the definition has not been changed for 14 years.

Just because a newer RFC claims that the protocol in an older RFC is "obsolete" does not mean that clients should suddenly start to interpret protocols which have a CLEAR version declaration as if they were outputs of a NEWER VERSION of the protocol. 

RFC 2109, 2965 and draft-23 are DIFFERENT protocols with different semantics and the parsers should treat them as such.

Comment 21

[Shawn Wilsher :sdwilsh]

(In reply to comment #20)
> This is a shame IMHO. You cannot suddenly change the semantics of a protocol
> after the definition has not been changed for 14 years.
Did you miss comment 14?  The standard wasn't a reflection of what browsers were/are actually doing.  The new draft brings the standard in-line with actual practices.

Comment 22

[xor]

And this should receive a special reply:

> The web isn't a static place, and standards do change.

Definitions/Specifications of the semantics communication protocols MUST NOT change.
Otherwise the corruption of the payload is guaranteed.

Nobody would allow this kind of crazyness if it happened in banking or other  critical things.
Imagine you had written the names of people who are allowed to withdraw money from your bank account in quotes and now suddenly your bank decides that quotation is invalid and defaults the permissions to EVERYBODY.

But in web development this is okay.

Really this attitude is why I hate web development.
Web developers are the lowest in the hierarchy of development.
We must deal with all kinds of invalid browser behavior, invalid HTML, invalid this, invalid that. Because the common attitude is to try to correct invalid documents instead of rejecting them.
Web development should have been like this from the beginning: One single character wrong in the HTML file => Browser displays NOTHING. Like it used to be with compilers for most ever known languages. Either you follow the specification or you do not. If you don't your document is ambiguous and invalid.
(Notice that I would accept this as a solution to the issue, its much better than the suggested patch which modifies the Path value. It should just reject the coookie instead if you do not plan to have a RFC2109-parser anymore. However IMHO you SHOULD have a RFC2109 parser as 2109-cookies have been in use for 14 years which Firefox proves itself by not even supporting Set-Cookie2)

Comment 23

[xor]

> --- Comment #21 from Shawn Wilsher :sdwilsh <[e-mail]>
> 2011-03-26 16:47:09 PDT --- (In reply to comment #20)
> 
> > This is a shame IMHO. You cannot suddenly change the semantics of a
> > protocol after the definition has not been changed for 14 years.
> 
> Did you miss comment 14?  The standard wasn't a reflection of what browsers
> were/are actually doing.  The new draft brings the standard in-line with
> actual practices.

Do you have any actual proof for that? Statistics? 

And even if you do: So the fact that developers are too incompetent to implement proper specification-compliant parsers does CHANGE the specification?
What the heck?
It is becoming more and more difficult for me to resist my temptation to say something which would fall under Godwin's law.

Comment 24

[Anthony]

(In reply to comment #23)
> > --- Comment #21 from Shawn Wilsher :sdwilsh <[e-mail]>
> > 2011-03-26 16:47:09 PDT --- (In reply to comment #20)
> > 
> > > This is a shame IMHO. You cannot suddenly change the semantics of a
> > > protocol after the definition has not been changed for 14 years.
> > 
> > Did you miss comment 14?  The standard wasn't a reflection of what browsers
> > were/are actually doing.  The new draft brings the standard in-line with
> > actual practices.
> 
> Do you have any actual proof for that? Statistics? 
> 
> And even if you do: So the fact that developers are too incompetent to
> implement proper specification-compliant parsers does CHANGE the specification?
> What the heck?
> It is becoming more and more difficult for me to resist my temptation to say
> something which would fall under Godwin's law.

It has nothing to do with this bug, really, but I have some statistics for you.

Although cookie av-pairs are allowed to have quoted values, including the Path av-pair (according to RFC2109 anyway), the majority of sites do not quote the Path value. Of the 11,746 Path av-pairs I encountered in my tests below, only one pair had a quoted value.

Alexa publishes a zipped-up .csv file on their Top 500 Sites page (http://www.alexa.com/topsites) that contains their list of the top 1,000,000 domains. About 1 month ago I wrote two Perl scripts to (1) query the top 10,000 domains and log their Set-Cookie/Set-Cookie2 responses to disk and (2) parse the results for a crude analysis of their weird features. This analysis was not a strict cookie parser - it was mainly looking for deviations from the various specs. I have to agree with you that web developers really suck at implementing and testing standards, which is why the web is such a mess now.

RFC2965 was introduced in October 2000, obsoleting RFC2109 from February 1997, which itself was supposed to replace the Netscape Cookie Specification Proposal from circa 1994.

A summary of my results:
1. There was one and only one Set-Cookie2 header (RFC2965) whose data was duplicated in a Set-Cookie header (NCSP).
2. RFC2109 required the Version=1 av-pair, which is rarely used - making the majority of Set-Cookie headers not compliant with RFC2109.
3. RFC2109 did not define an Expires=datetime av-pair, but it is issued in the majority of Set-Cookie headers thus making them not compliant with RFC2109.
4. The majority of Set-Cookie headers encountered are mutations of the original Netscape Cookie Specification Proposal, varying mainly in the date format used in their Expires av-pair.
5. There were more Set-Cookies than domains tested because a number of sites issue multiple cookies - one of them sent 66!
6. The NCSP used different date formats in its definitions and examples, leading to a plethora of date formats being used in the wild. The majority of "unknown" date formats below looked like either Unix systime integers or XML-like date time values (even those weren't correct).

I sincerely hope in the interests of interoperability and security that the RFC coming out of http://tools.ietf.org/html/draft-ietf-httpstate-cookie-23 is used by the majority of application vendors and site developers, but given the current state of play I doubt this will ever come to pass. Developers are lazy and web developers seem even more so.

Here are the numbers I came out with:

Set-Cookie count (including empty ones): 12235
Set-Cookie2 count (including empty ones): 1

Comment count: 5 (0.0409% of all cookies)

CommentURL count: 0 (0.0000% of all cookies)

Cookie count: 12231 (100.0000% of all cookies)
Cookie missing-= count: 3 (0.0245%)
Cookie name whitespaced count: 2 (0.0164%)
Cookie value empty count: 487 (3.9817%)
Cookie value quoted count: 116 (0.9484%)
Cookie value whitespaced count: 3 (0.0245%)
Cookie value backslashed count: 5 (0.0409%)
Cookie value slashed count: 219 (1.7905%)

Discard count: 0 (0.0000% of all cookies)

Domain count: 5537 (45.2702% of all cookies)
Domain value empty count: 3 (0.0542%)
Domain value quoted count: 1 (0.0181%)
Domain value slashed count: 4 (0.0722%)

Expires count: 6837 (55.8989% of all cookies)
Expires value quoted count: 3 (0.0439%)
Expires value Netscape cookie_spec Definition YY Format count: 212 (3.1008%)
Expires value Netscape cookie_spec Definition YYYY Format count: 6032 (88.2258%)
Expires value RFC 850 YY Format count: 22 (0.3218%)
Expires value RFC 850 YYYY Format count: 145 (2.1208%)
Expires value RFC 1123 YY Format count: 2 (0.0293%)
Expires value RFC 1123 YYYY Format count: 350 (5.1192%)
Expires value RFC 2822 YYYY Format count: 1 (0.0146%)
Expires value Unrecognized Format count: 73 (1.0677%)

Host count: 6 (0.0491% of all cookies)

HttpOnly count: 1240 (10.1382% of all cookies)
HttpOnly missing-= count: 1237 (99.7581%)
HttpOnly value empty count: 1240 (100.0000%)

Max-Age count: 137 (1.1201% of all cookies)

Path count: 11746 (96.0347% of all cookies)
Path value empty count: 10 (0.0851%)
Path value quoted count: 1 (0.0085%)
Path value whitespaced count: 5 (0.0426%)
Path value slashed count: 11736 (99.9149%)

Port count: 0 (0.0000% of all cookies)

Secure count: 83 (0.6786% of all cookies)
Secure missing-= count: 83 (100.0000%)
Secure value empty count: 83 (100.0000%)

Version count: 110 (0.8994% of all cookies)

Comment 25

[xor]

Comment #24 => VERY nice work. Finally someone took the effort to do actual statistics. Thank you very much! The results are a shame for web developers :|

I guess I will have to surrender to the fact that almost nobody else seems to use quotes. 

However, the patch which makes "-containing paths just be ignored still should not be wired in IMHO. The cookie should be rejected to prevent leakage of cookie information as I described in Comment #17.

Comment 27

[[e-mail]]

Comment on attachment 522143 [details] [diff] [review]
Patch to fix handling of bogus cookie paths

Awesome, thanks Adam. (This doesn't need superreview.)

Would someone like to volunteer to push this up to tryserver and land it? I don't have much time these days to look at trees.

Comment 28

[Adam Barth]

Thanks Dan.

Comment 29

[Boris Zbarsky [:bzbarsky]]

I pushed http://hg.mozilla.org/try/rev/ce76db0d0326

Comment 30

[(no longer active)]

http://hg.mozilla.org/mozilla-central/rev/283a54188c6c

Comment 31

[Benjamin Smedberg]

Given the commentary here, this should probably undergo a security review, and we definitely need to make sure that it is documented for developers.

Comment 32

[Eric Shepherd [:sheppy]]

Documentation updated:

https://developer.mozilla.org/en/DOM/document.cookie

Mentioned on Firefox 6 for developers: