Expose the attached HTML document on a webserver running on localhost. (For your convenience, I've provided a simple python script to expose a webserver on port 8000. Just save tinyWebServer.py and weird_cookies.html in the same directory and then run tinyWebServer.py.) Open WebKit and browse to the URL at http://localhost:8000/weird_cookies.html Click on "testCookies". You'll get a message: "No Cookies!" Click on "addCookie". You'll get a message: "cookie added". Click on "testCookies" again. You'll get the old message: "No Cookies!" but at this point it should say "Got Cookies!" Now browse to the URL http://127.0.0.1:8000/weird_cookies.html Click on "testCookies". You'll get a message: "No Cookies!" Click on "addCookie". You'll get a message: "cookie added". Click on "testCookies" again. You'll get a message: "Got Cookies!" Using WebKit-r23922 built on 02 July 2007 on Windows XP SP2.
Created attachment 15373 [details] Test case, modeled after example on developer.apple.com
Created attachment 15374 [details] tiny web server for your convenience
I haven't yet tried to investigate this issue, but cookie-related bugs tend to be caused by issues in closed source system frameworks, and not in WebKit. So, it may be also useful to file this issue at <http://bugreport.apple.com> for Apple engineers to take a look (free registration required). If you do so, please mention this Bugzilla bug in your report, and also please post Apple's problem ID here.
I'm seeing this too (Mozilla/5.0 (Windows; U; Windows NT 5.1; en) AppleWebKit/522.15.5 (KHTML, like Gecko) Version/3.0.3 Safari 522.15.5). It's not just "localhost" that doesn't work. If I use my machine name in place of "localhost" in a page URL, cookies created in script on the client do not "stick." They behave properly if I specify an IP address, whether it's the loopback address or the machine's actual IP address. Cookies created on the server (using the same host string) also work. Note that the attached tiny web server is only necessary if you want to see cookies operating correctly (by specifying an IP address). If you want to see the broken behavior, you can just save the test case to disk and load it with a file: URL. I'd hazard a guess that the problem is related to IP addresses versus names (which have to be resolved).
Apple problem ID 5453809. I can also get this to occur using the file: scheme on a PowerPC with Safari 2.0.4 on OS X 10.4.10. localhost works, however, so this appears to be a regression.
<rdar://problem/5453809>
Jesse, please clarify (in here or in the Radar or both :) which platforms and versions of Safari/WebKit have which behaviors. Thanks!
Here's what I can test. Version 2 in the table below is Safari 2.0.4 (419.3) running on PowerPC Mac OS X 10.4.10; version 3 is Safari 3.0.3 (522.15.5) running on Windows XP. In each case, the browser and server are running on the same machine, and the first attachment is the test page. In the version 2/OS X case, I used the tiny server attached to this bug (on port 8000). In the version 3/Windows XP case, I used IIS (on port 80), since it's already running on my machine. Version | localhost | <host name> | 127.0.0.1 | <real IP address> | file: --------+-----------+-------------+-----------+-------------------+------ 2 | succeeds | succeeds | succeeds | succeeds | fails 3 | fails | fails | succeeds | succeeds | fails For completeness, I ran an additional test. Using Safari 3 on XP, I loaded the test case from the Macintosh. Once again, if I specify the host name, the test fails, but if I specify an IP address, it succeeds. Bottom line: Safari 3 on Windows fails when the host is specified by URL, where Safari 2 on OS X succeeds. The obvious next question is what happens with Safari 3 on OS X. I'm a little reluctant to do the necessary install, but will do so if necessary (particularly if no one else can reproduce this with Safari 3 on a Mac).
This is probably old news to those in the know, but this looks like it's in Safari, not WebKit. I've downloaded various WebKit nightlies (including r24749, r24761, and r25353), and they all seem to work the same as Safari 2 on a MacBook Pro with OS X 10.4.10 with Safari 2 installed. (It sure would be nice if I could tell for sure whether I'm running a version of WebKit substantially similar to 522.15.5. "522+" doesn't tell much.)
Per comments 8 and 9, this sounds like a regression. I haven't had the time to look into this bug yet, but it may be in closed source code anyway per the above.
(In reply to comment #8) > | file: > +------ > | fails > | fails Setting cookies on a file:/// URL is Bug 6339. Did a radar ever get filed for this?
(In reply to comment #11) > Setting cookies on a file:/// URL is Bug 6339. Did a radar ever get filed for > this? And yes: <rdar://problem/4507584>
(In reply to comment #8) > Bottom line: Safari 3 on Windows fails when the host is specified by URL, where > Safari 2 on OS X succeeds. The obvious next question is what happens with > Safari 3 on OS X. I'm a little reluctant to do the necessary install, but will > do so if necessary (particularly if no one else can reproduce this with Safari > 3 on a Mac). The Safari 3 Public Beta v. 3.0.3 (522.12.1) with a local debug build of WebKit r25410 on Mac OS X 10.4.10 (8R218) behaves the same as the Safari 2 row in Comment #8. (NOTE: I did NOT test file:/// URLs.) I also tested Safari 2.0.4 (419.3) with its original WebKit on 10.4.10. It has the same results as well. This looks like a Windows-only issue; adding PlatformOnly keyword. (I can't confirm it because I don't have a Windows box to test on.)
* STEPS TO REPRODUCE 1. Download weird_cookies.html (Attachment #15373 [details]) and place on local web server. (These tests assume the web server listens on Port 8000.) 2. Access http://localhost:8000/weird_cookies.html. 3. Click "testCookies" button. 4. Verify that "No Cookies!" message appears. 5. Click "addCookie" button. 6. Click "OK" to dismiss alert. 7. Click "testCookies" button. 8. Verify that "Got Cookies!" message appears. 9. Click "deleteCookie" button. 10. Click "OK" to dismiss alert. 11. Click "testCookies" button. 12. Verify that "No Cookies!" message appears. Repeat steps 3-12: - Replacing "localhost" with "127.0.0.1". - Replacing "127.0.0.1" with the hostname of your computer. - Replacing the hostname of your computer with your computer's IP address.
I overcame my reluctance to install the beta on PowerPC 10.4.10. It too behaves as described in the Safari 2 row of comment #8. Since the OS X beta works for me but the Windows beta does not, I think David is right to flag this as PlatformOnly. What's necessary to mark this as NEW? Is there someone with WebKit bugzilla karma and a Windows machine who can run the test case?
(In reply to comment #15) > I overcame my reluctance to install the beta on PowerPC 10.4.10. It too behaves > as described in the Safari 2 row of comment #8. Since the OS X beta works for > me but the Windows beta does not, I think David is right to flag this as > PlatformOnly. If you still need to run Safari 2, here's one way (other than uninstalling the beta): http://trac.webkit.org/projects/webkit/wiki/UsingSafari2WithSafari3PublicBetaInstalled > What's necessary to mark this as NEW? Is there someone with WebKit bugzilla > karma and a Windows machine who can run the test case? I'll go ahead and confirm the bug; you've certainly done more than enough testing. :)
Think I have same problem we have keep alive between vendor package and our host site. When ip address this worked on Safari and Netscape but not IE(IE did not accept 3rd party cookies). So we went to a shared domain which is url not ip adress. Now works on Netscape and IE but not Safari. Logged this on Apple's discussion board
(In reply to comment #17) > Think I have same problem we have keep alive between vendor package and our > host site. When ip address this worked on Safari and Netscape but not IE(IE > did not accept 3rd party cookies). So we went to a shared domain which is url > not ip adress. Now works on Netscape and IE but not Safari. Logged this on > Apple's discussion board Robert, could you provide a link to the message board discussion? Thanks!
Closing as INVALID, as this is an issue in closed source frameworks. The problem will continue to be tracked in Radar.
I can no longer reproduce this with Safari 3.0.4 for Windows. I think this was fixed in Apple's closed source frameworks that shipped with this version; please verify.
Works for me with Safari 3.0.4 on Windows and OS X 10.4.