User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:22.214.171.124) Gecko/20091016 Firefox/3.5.4 (.NET CLR 3.5.30729) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:126.96.36.199) Gecko/20091016 Firefox/3.5.4 (.NET CLR 3.5.30729) Alternate ways of specifying URL are not treated the same even when the location bar display is the same. Example -- www.asstr.com/%7Ename and www.asstr.com/~name are both displayed in the later form but they are treated as different paths in the cookies list. Reproducible: Always Steps to Reproduce: 1.create a web page with a ~ in the name that writes a cookie. 2.access using ~ and %7E in the url. 3.note that the url in the location bar always shows ~ once the page is accessed. 4.note that there are two cookies with different paths in the cookie list. Actual Results: I get two cookies based on "different" paths that look the same to me in the location bar since the encoding is always converted back to simple characters. Expected Results: The url is displayed the same so should have the same cookie path. Also the same problem in Opera and Safari(win) IE7 does this correctly.
Component: General → Networking: Cookies
Product: Firefox → Core
QA Contact: general → networking.cookies
Version: unspecified → 1.9.1 Branch
This seems to be intendent if I read bug 269751 comment#1
I have found a reference which I believe supports my case that when the given URL is equivalent to the one displayed the path name should also be the same. Intuitively it is the way that people operate. Please see: http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html which is part of "Hypertext Transfer Protocol -- HTTP/1.1" The relevant section is: <quote> 3.2.3 URI Comparison When comparing two URIs to decide if they match or not, a client SHOULD use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: - A port that is empty or not given is equivalent to the default port for that URI-reference; - Comparisons of host names MUST be case-insensitive; - Comparisons of scheme names MUST be case-insensitive; - An empty abs_path is equivalent to an abs_path of "/". Characters other than those in the "reserved" and "unsafe" sets (see RFC 2396 ) are equivalent to their ""%" HEX HEX" encoding. For example, the following three URIs are equivalent: http://abc.com:80/~smith/home.html http://ABC.com/%7Esmith/home.html http://ABC.com:/%7esmith/home.html </quote>
We already perform normalization of the host before comparison - UTF8 characters are normalized to ACE, for instance, and everything is lowercased. My gut reaction is that we should unescape the path. CC'ing dveditz and Adam Barth in case they have thoughts on this.
I can write a test for the http-state test suite and give you a survey of what other browsers do here. I'll be able to do that in the next couple of days.
A simple test writing a cookie with URL= host/~path and then attempting to read with URL = host/%7epath yields the following The cookie is found: IE7 and Chrome3 -- Yes FF3, Opera10 and Safari4(windows) -- No The URL in the address bar is changed to <host/~path> from <host/%7epath>: IE7, Chrome3, FF3, and Opera10 -- Yes Safari4(windows) -- No
I agree with Dan and the reporter that we should follow IE and the RFC here.
(In reply to comment #5) > The URL in the address bar is changed to <host/~path> from <host/%7epath>: > IE7, Chrome3, FF3, and Opera10 -- Yes > Safari4(windows) -- No Hmm. So Safari4 just doesn't set (or otherwise doesn't render accessible) the cookie for <host/~path> at all? Curious.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows Vista → All
Hardware: x86 → All
Version: 1.9.1 Branch → Trunk
(In reply to comment #7) Safari considers <host/~path> and <host/%7Epath> as different as <host/~path2>. I don't have the tools to determine if Safari or the host server does the unescaping to fetch the correct page. Permit me to explain in more detail. Consider a web page at host/~abc/file.htm with a relative link to secondfile.htm. =================== In IE7 start with url=host/~abc/file.htm and write a cookie I get address bar = host/~abc/file.htm cookie host = host cookie path = ~abc link page in address bar = host/~abc/secondfile.htm and cookie with path= ~abc is available start with url=host/%7Eabc/file.htm and write a cookie I get address bar = host/~abc/file.htm cookie host = host cookie path = ~abc link page in address bar = host/~abc/secondfile.htm and cookie with path= ~abc is available It appears that IE unescapes the URL at the beginning and there is never any ambiguity. (I think that this is the correct way and in accordance with the RFC previously quoted.) ====================== In FF 3.5 start with url=host/~abc/file.htm and write a cookie I get address bar = host/~abc/file.htm cookie host = host cookie path = ~abc link page in address bar = host/~abc/secondfile.htm and cookie with path= ~abc is available start with url=host/%7Eabc/file.htm and write a cookie I get address bar = host/~abc/file.htm cookie host = host cookie path = %7Eabc link page in address bar = host/~abc/secondfile.htm and cookie with path= %7Eabc is available It appears that FF unescapes the URL for display but not internally so that relative link are still escaped as is the cookie path. (I think that this is confusing behavior.) ======================= In Safari4(windows) start with url=host/~abc/file.htm and write a cookie I get address bar = host/~abc/file.htm cookie host = host cookie path = ~abc link page in address bar = host/~abc/secondfile.htm and cookie with path= ~abc is available start with url=host/%7Eabc/file.htm and write a cookie I get address bar = host/%7Eabc/file.htm cookie host = host cookie path = %7Eabc link page in address bar = host/%7Eabc/secondfile.htm and cookie with path= %7Eabc is available It appears that Safari never unescapes the URL so that the two are different in all places. (I think that this is consistent but incorrect.)
Here's my test case. The server responds with a redirect and the following headers: Set-Cookie: foo=bar; path=/cookie-parser-result/f%6Fo/bar Location: /cookie-parser-result/foo/bar?path0028 When the browser (IE8, Firefox 3.5, Safari 4, Chrome 4) arrive at /cookie-parser-result/foo/bar?path0028, the cookie is not visible. The only browser I've tested that behaves as you describe (i.e., unescapes the path before comparing against the path) is Opera 10. I've added this to the http-state test suite as path0028. Can you supply a working test case (e.g., a server) that reproduces the issue you're seeing?
> Change the location bar to > http://www.asstr.org/%7EYLeeCoyote/yourway.htm > and repeat with different value(s). Note in IE the first cookie is found but > not in FF. I understand now. I suspect the issue is not whether the path comparison algorithm in the cookie manager is sensitive or insensitive to URL escaping, the issue is that Firefox is not canonicalizing URLs entered in the location bar. Can you reproduce the issue without typing in the location bar (e.g., by following hyperlinks or redirects)?
(In reply to comment #11) > Can you reproduce the issue without typing in the location bar (e.g., by > following hyperlinks or redirects)? The short answer is YES. In fact, that is how I found the problem for I followed a link that was escaped. If I enter a url such as .../%7Epath.... or follow such a link I get the same results. The location bar display is .../~path... but the cookie path is /%7Epath. If the page has a relative link, then the linked (second) page is .../%7Epath/secondfile... rather than .../~path/secondfile.... But if the first page has a base tag with href=".../~path..." then the second page is now .../~path/secondfile... and uses the other cookie. With the confidence of great ignorance of internals, I suggest that the original url is stored as the "location" and then it is unescaped for display in the location bar. The original location is used for the cookie path and for base for relative links. I suggest that the original url should be unescaped BEFORE it is storied as the "location" and then all would be consistent.
> If the page has a relative link, Oh, I meant by following hyperlinks from a URL that doesn't have this issue. It's clear that once you confuse Firefox by typing this kind of URL into the location bar that Firefox can remain confused. The question is can it get confused without typing in the location bar.
(In reply to comment #13) YES. You can see this by using the example I gave in #10 above. Go to both links and set different parameters so that you can tell which cookie is being used. Then go back and use the link on that page "return to directory" (another page that uses the cookie data) to is see that the %7E form is retained as the "internal location" when you start with the second link even though it is displayed with the ~.
I see. Yeah, this behavior is definitely wrong. The problem seems to be that the cookie manager is using the unescaped URL instead of the canonicalized URL. Thanks for being patient with me.
Summary: Alternate URL encodings are not the same → Alternate URL encodings are not the same (normalization)
There is a circular "duplicate" mark between this bug and 665851.
Are there any plans for fixing this issue ? I'm asking because it's *not* only an annoyance. It makes firefox incompatible to some websites, as soon as you need session cookies.
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.