I would expect that a cookie without a path would be treated like a cookie with the path '/' (coming from Set-Cookie: ...; path=/). But Mozilla stores these as two different cookies, which can be verified by opening the cookie manager. Additionally, Mozilla sends this cookie twice to the server (like this: Cookie: max=50; max=200), where the second one is the one with the path '/'. And what's more annoying: it is impossible to remove the cookie without a path with a Set-Cookie:-request, at least not with an expiration time in the past and without a specified path. Unfortunately, IE handles all this like I would expect. :-( I could provide a PHP script as a test case, if that would help. The essential part is that I used to set a cookie with setcookie( 'max', $max, time() + 90*24*60*60 ); and now that I included a path in a newer version like this: setcookie( 'max', $max, time() + 90*24*60*60, '/' ); I would like to remove the old cookie like this: setcookie( 'max', '', 1 ); You can find the description of the setcookie function at http://php.net/setcookie . I'm using nightly build 2000112620 in NT4 at the moment, but I don't think that matters, so I'm setting Platform and OS to all.
Will make testcase a.s.a.p. Friendly, HJ.
Netscape Nav triage team: this is not a Netscape beta stopper.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.2
More info: It seems the RFC 2109 regarding cookies is more recent than Netscape's specification. It states at http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2109.html#sec-4.3.1 Path Defaults to the path of the request URL that generated the Set-Cookie response, up to, but not including, the right-most /. This is exactly what mozilla does at the moment, but I still think it's a bug because the RFC authors didn't consider the query string (the part following the "?") and the "/"'s it might contain. I am CC'ing them, maybe they can confirm my theory? Once again: for the URL http://example.com/dir/script?param1=abc¶m2=de/fg¶m3=gh I think the path should default to http://example.com/dir and not to http://example.com/dir/script?param1=abc¶m2=de David and Lou, please comment.
If there was a slash in the query string, it would probably need to be escaped.
Created attachment 74330 [details] [diff] [review] Use path up to first "?", then try last "/" This patch is to the 0.9.9 source. I couldn't test it because I don't have a build environment ready. It should strip down everything after the first question mark to get the path. If there is no question mark, the old behaviour is used.
Well, for one the "slash" character is considered a reserved character in the query string and needs to be escaped. THerefore, it should NEVER appear unescaped in the query string. See W3C doc - http://www.w3.org/Addressing/URL/uri-spec.html Section: BNF of generic URI syntax reserved = | ; | / | # | ? | : | space Therefore the spec is correct and the URL that fails does so because it is an inproperly formed URL (and should fail).
I'm not sure if it needs to be escaped. Does RFC 1630 page 7 "QUERY STRING" or RFC 2396 section 3.4 apply? RFC 2396 does not claim to supersede or update RFC 1630. A page with an unescaped "/" in the query string passes through the "HTML 4.01 strict" validator at the W3C. There are lots of pages that don't encode "&" (as "&") and "/" properly in the query string. It would be good of mozilla would tolerate such errors in this simple case.
Email to both authors of RFC 2109 bounces. If an unescaped "/" is illegal in the query part of the URL, i think mozilla should ignore it in its attempt to determine the path. This is what my patch does.
There is an issue with my patch. For the URL http://example.org/a/b?c the path will be http://example.org/a/b but it should be http://example.org/a Could someone come up with a better patch? It should find the last slash in the URL, but not past the first question mark.
Why not just use this algorithm: 1. Parse the URL on the "?" into an object (like an array) 2. Take the first element of the object, get the position of the last instance of the "/" character 3. Using that position, get the substring from 0 --> position 4. There's your path :)
Created attachment 74346 [details] [diff] [review] Find last "/" but not past first "?" This one works like before with query strings that don't have "/" in them. It obsoletes my attachment 74330 [details] [diff] [review] (i'm not authorized to check the box.. bleh).
Comment on attachment 74330 [details] [diff] [review] Use path up to first "?", then try last "/" buggy. obsoleted by attachment 74346 [details] [diff] [review]
Attachment #74330 - Attachment is obsolete: true
I'm not convinced there is a problem here. If the query string contains an unescaped /, then the query string is incorrectly formed (comment 7 and comment 9) and we have an evangelism issue. However if IE is tolerant enough to accept this malformed query, then perhaps we should be too. That said, the patch that you are proposing is indeed the correct way to handle this. My only criticism is the use of the variable name "slash" since you are using it when you look for the questionmark too. Change that to a more generic name, such as pathEndChar or something equivalent. With that change, r=morse. Now you need to get yourself an sr.
*** Bug 121355 has been marked as a duplicate of this bug. ***
OK, there are starting to be dups on this one, and I'm afraid there are going to be many sites that will fail because of this problem. Even though it's an evangelism issue for those sites, we are the ones that are going to get the blame. Therefore I'm going to recommend that this one be considered for nsbeta1. Especially since we already have a patch for it and it's probably of low risk.
Target Milestone: mozilla1.2alpha → mozilla1.0
Nav triage team needs info: What is the real impact here? Does this affect any top sites?
Whiteboard: [need info]
I have no idea whether any top sites are affected. We won't know the answer to that until after we release the product and start getting complaints. This is a case where we can avoid the problem completely with a relatively safe fix that already exists (thanks to a web contributor). So why should we not use it?
sr=jag provided Morse's comment about the variable name is addressed. A common name for such variables is |iter|.
Comment on attachment 74346 [details] [diff] [review] Find last "/" but not past first "?" a=asa (on behalf of drivers) for checkin to the 1.0 branch
Attachment #74346 - Flags: approval+
Checked in on trunk. Can't check in on branch due to lack of adt approval.
Created attachment 79405 [details] [diff] [review] Same as attachment 74346 [details] [diff] [review], but with better variable name Here's the patch again with the requested name change. Thanks for considering it for 1.0.
Attachment #74346 - Attachment is obsolete: true
Sven, thanks for the updated patch. It's exactly what I've already checked in on the trunk before you made your latest posting (I had made those same changes based on my comments and jag's).
Just curious - is there a "contributers" file or something I get added to for fixing this problem? :-)
Thank you Steve, Sven! This fixed the problem in bug 121355. Hopefully we will get approval for the branch before release.
tever, please test the bug fix on the trunk and add your comments here. The adt needs to know before the fix is checked into the branch. thanks.
Nav triage team: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
Samir, what's the reason for the nsbeta-? Please check morse's comment 18 as well as comment 21. Since the patch is checked into the trunk (and fixes the problem with the site), should this be renominated nsbeta after a few days of baking?
adt1.0.0- on behalf of the adt. Not needed for MachV.
This bug is still present in 1.0rc2 it seems. Does this mean it won't make it into 1.0? I can't access a site with mozilla because of this. It works fine in all other major browsers.
Sven, see comments 24, 30, and 32. Unless it gets adt1.0.0+ it can't go into the branch.
*** Bug 144148 has been marked as a duplicate of this bug. ***
removing minus to get back on ADT radar.
Keywords: adt1.0.0- → adt1.0.0
Being marked fixed since it is checked in on trunk, even though it is still not fixed on the branch.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Keywords: nsbeta1- → nsbeta1
Resolution: --- → FIXED
Please get an nsbeta1+ from the nav-triage team before seeking ADT approval.
nsbeta1+ per Nav triage team, since minimal Nav team work is required.
Keywords: nsbeta1 → nsbeta1+
adt1.0.0+ (on ADT's behalf) for approval to checkin to the 1.0 branch, pending Driver's re-approval (e.g. a= is older than 3 days). After, checking in, please add the fixed1.0 keyword.
Whiteboard: [need info][fixed-trunk] → [need info][fixed-trunk] [Needs refresh of a=]
changing to adt1.0.1+ for adt approval for checkin to the 1.01 milestone. Please get drivers approval before checking in.
Keywords: adt1.0.0+ → adt1.0.1+
Comment on attachment 79405 [details] [diff] [review] Same as attachment 74346 [details] [diff] [review], but with better variable name re-approval for 1.0.1 branch. please check into the 1.0.1 branch ASAP. once landed remove the mozilla1.0.1+ keyword and add the fixed1.0.1 keyword
See bug 135932 which is a consequence of this bug.
*** Bug 150953 has been marked as a duplicate of this bug. ***
I realize I'm wandering into this discussion rather late, and it's good to know that this bug is being fixed. I think that this is a parsing issue more than anything--in this case, how to parse certain invalid URLs. <a href="http://www.w3.org/Addressing/rfc1808.txt">RFC 1808</a> has some good guidelines on how to parse URLs. Obviously, mozilla itself doesn't mistake a URL of the form "http://foo.com/bar?moby/quux" as referring to the path "/bar?moby", because then it wouldn't be parsing the query correctly. Whether or not the query is invalid or contains a '/' is really a separate issue--the path for the cookie is only supposed to concern the URL's path, not its query. Sure, the query is incorrectly formed, but that shouldn't be relevant to the path at all, any more than an incorrectly formed hostname or fragment would be. And if these URLs really are invalid, why doesn't Mozilla give me an error? My guess would be because its URL parsing works something like the method specified in RFC 1808, and therefore is rather forgiving in what it accepts. The problem here is that Mozilla silently sets the wrong path for the cookie; a warning or an error would have been much easier to diagnose. :) But it's great to hear that this has been fixed; I just wish it could have made it into Netscape 7.0PR1, since people are starting to use it now. I'll download a nightly build of Mozilla and test it again...
Status: RESOLVED → VERIFIED
verified galeon 1.2.6 + Mozilla 1.1
You need to log in before you can comment on or make changes to this bug.