Closed Bug 195391 Opened 22 years ago Closed 22 years ago

cookies for background color and font size are not being set properly

Categories

(Core :: Networking: Cookies, defect)

defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: brant, Assigned: dwitte)

References

()

Details

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030226 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030226 In a recent build of Mozilla including this current build, Mozilla seems to have quit accepting the cookies I have set for background color and font size. These are being set properly in Internet Explorer, however. I think I read that there have been some recent cookie code changes so I though this might be related. Reproducible: Always Steps to Reproduce: 1. Set Headlines. (works) 2. Set Columns. (works) 3. Set Font Size. (does not work) 4. Set Background Color. (does not work) Actual Results: The Font Size and Backgroudn Color are stuck at their default values. Expected Results: It should set the appropriate cookies. More details of this problem may be found in the message thread at <http://www.shellcity.net/phpBB/viewtopic.php?topic=2363&forum=5&start=0>.
*** Bug 195392 has been marked as a duplicate of this bug. ***
OS: All - seeing this on Linux to.
OS: Windows XP → All
Hardware: PC → All
I looked at this with ethereal, and this is what I guess is the problem: Cookies are not send when requesting http://domain/path when the path that the cookie has is /path (In this case, path is the complete filename, /blah/style.cgi) From an old build: [michiel@epsilon bin]$ ./run-mozilla.sh ./TestCookie setting cookie for "http://blah/path/file" : "aaa=bbb; path=/path" was set. retrieving cookie(s) for "http://blah/path" : FOUND: aaa=bbb retrieving cookie(s) for "http://blah/2path2" : NOT-FOUND A recent build: [michiel@epsilon bin]$ ./run-mozilla.sh ./TestCookie setting cookie for "http://blah/path/file" : "aaa=bbb; path=/path" was set. retrieving cookie(s) for "http://blah/path" : FOUND: retrieving cookie(s) for "http://blah/2path2" : FOUND: retrieving cookie(s) for "http://blah/path/" : FOUND: aaa=bbb From rfc 2109: "The Path attribute of the cookie must match a prefix of the request-URI." So the first test in the new build should return the cookie. I guess this comes from dwitte's first part of the cookie rewrite (bug 177698)
-> dwitte increasing severity. we are likely to see this problem on many other sites.
Assignee: darin → dwitte
Severity: major → critical
Flags: blocking1.4a?
Attached patch Move the test for pathlength (deleted) — Splinter Review
The test for the length of the path was too early. I'm not sure what happens when cookiePathLen > path.Length(). Will substring break then? Leaving this patch to dwitte to take care of, and to figure the above out :)
Comment on attachment 115998 [details] [diff] [review] Move the test for pathlength sorry for the regression :) Substring behaves fine if you ask for more length than the string has, so that's fine. mvl also fixed another 'bug' - ToNewCString will return a valid ptr if the string is empty, but previously we return nsnull. Best to keep behavior consistent until we can get a proper return code out of GetCookie (new API)... r=dwitte.
Attachment #115998 - Flags: superreview?(darin)
Attachment #115998 - Flags: review+
Comment on attachment 115998 [details] [diff] [review] Move the test for pathlength sr=darin
Attachment #115998 - Flags: superreview?(darin) → superreview+
thx timeless
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Flags: blocking1.4a?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: