I've noticed that if I'm working on an HTML file locally (accessing it via file:// protocol from my desktop for example) that if that page tries to set cookies, the cookies will fail to be set. That same file as viewed under my Sites directory (via http:// in apache) will set the cookies proplery. I believe that Safari should allow cookies to be set for local files. Firefox allows this, and it's really handy for doing development locally, where using apache may not be the best method for development. So I'm assuming this is a bug, unless there's a reasoning for it not working under this situation, which I'd like to hear in that case.
Confirmed. Needs a proper way to test though.
*** Bug 8216 has been marked as a duplicate of this bug. ***
This seems to be an NSHTTPCookie bug, filed as <rdar://4507584>. Keeping this bug open for now to investigate if a temporary workaround is possible.
Created attachment 7579 [details] temporary workaround
Comment on attachment 7579 [details] temporary workaround I don't think this is a good way to handle this, although perhaps I could be convinced.
(In reply to comment #5) This is the only workaround I could find that looked safe... Firefox displays an empty domain for such cookies, and Opera displays localhost (which makes to wonder if cookies from http://localhost URLs can get confused with file:// ones there).
I'm curious why there may be no good way to handle this (what are the concerns)? I believe Safari is the only browser on the market that does not allow this functionality. I'm using Webkit to build several web apps that run locally (not through Apache, which I can't use for this) and not having cookies is severly limiting the development because I can't maintain state from one session to the next.
(In reply to comment #7) > I'm curious why there may be no good way to handle this. There's definitely a good way to handle this! Since this is a bug in NSURLConnection cookie handling, we should get the bug in NSURLConnection fixed. The question at hand is whether we should work around the NSURLConnection bug in WebKit, while we wait for an NSURLConnection fix. The technique in Alexey's is to store "file:" cookies under the semi-bogus "http://0.0.0.0" URL. It's a clever idea, but clearly a hack. And it's something we'd want to remove some day, which is why Alexey calls it temporary. The things that seem bad about the hack are: 1) The hack would show through in Safari's user interface -- the http://0.0.0.0 URLs would show up. 2) Once the bug in NSURLConnection is fixed, we'd want to remove the hack, which would probably mean you'd lose all cookies stored by earlier versions with the hack. 3) If someone runs into it, they'd have to figure out what http://0.0.0.0 really means. I guess those concerns are relatively minor. I'd like to hear what some of the other WebKit project leaders think. > I'm using Webkit to build several web apps that run locally (not through > Apache, which I can't use for this) and not having cookies is severly limiting > the development because I can't maintain state from one session to the next. Understood.
(In reply to comment #7) > I'm using Webkit to build several web apps that run locally (not through > Apache, which I can't use for this) and not having cookies is severly limiting > the development because I can't maintain state from one session to the next. One thing I'd like to stress is that this is an end user issue, not only a developer one (see bug 8216, and this is probably not the only eBook that doesn't work because of this).
This bug has been sitting here a long time. I'm going to r- this because we'd much rather have this fixed at the NSURLConnection level, since the fix there can be much cleaner. I will also point the appropriate team at Apple to this bug.
Comment on attachment 7579 [details] temporary workaround Marking r- as per Maciej's comment.
This functionality is supported by virtually ALL other browsers. Breaks all DHTML/HTML/javascript applications intended to run from local installs or CD/DVD. Please add the "local server" - "file://" to the sites alowed to store/read cookies.
Come on Development. The first entry for this bug is January 2, 2006. This is not a minor bug. You deploy Safari bundled with new systems, which will NOT be capable of prpperly viewing Ebooks and many other Browser-based applications too large/slow to execute over the WEB. Please FIX this.
All - This bug really needs to be fixed. Our file-system based launching code is really hampered without cookie support. I'd love it if this could be fixed before Safari 3.0 goes final. Therefore, I will make the same offer I've made with some success over at the Mozilla project: The person who fixes this bug and gets checkin approval in time for Safari 3.0 final will receive a case of beer or bottle of wine of their choice (within a reasonable price range :-) ). Any takers? Cheers, - Bill
Please note that this bug is only kept open for tracking purposes. No one is going to work on it here, since the issue is really in closed source Apple frameworks, and Apple engineers are investigating it. If it turns out that the root issue cannot be addressed in time, we may reconsider applying a workaround. And if the problem is also present in other ports (such as Safari for Windows), please file separate bugs!
Actually closing as INVALID, as this is an issue external to WebKit.
It would be interesting to know if this is fixed on the Safari 3 Public Beta for Windows.
Created attachment 16241 [details] test case (In reply to comment #17) > It would be interesting to know if this is fixed on the Safari 3 Public Beta > for Windows. Looks like it's not.
(In reply to comment #18) > Created an attachment (id=16241) [edit] > test case > > (In reply to comment #17) > > It would be interesting to know if this is fixed on the Safari 3 Public Beta > > for Windows. > > Looks like it's not. <rdar://problem/5470773>
Who at WEBKIT has ownership of this problem as reported??? Maybe/maybenot a WEBKIT prob. but a serious one that needs to be escalated with the MAC folks. It is falling through the crack, as evidened by the fact that it has been open for so long and the new release shows the same behavior. We at our company CANNOT pick Safari as a browser as long as this remains a problem. If this is a progressive browser, THEN GET THIS FIXED.
(In reply to comment #20) > Who at WEBKIT has ownership of this problem as reported??? Maybe/maybenot a > WEBKIT prob. but a serious one that needs to be escalated with the MAC folks. > It is falling through the crack, as evidened by the fact that it has been open > for so long and the new release shows the same behavior. We at our company > CANNOT pick Safari as a browser as long as this remains a problem. If this is a > progressive browser, THEN GET THIS FIXED. Thomas, this issue is known to Apple by the fact that two Radar (internal Apple) bug reports have been opened for it (one for Safari for Mac OS X and one for Safari for Windows). The bug does not occur in the WebKit project itself, which is why this specific Bugzilla bug has been closed as RESOLVED/INVALID. Please be patient.
This bug has been fixed in Mac OS X 10.5 Leopard.
*** Bug 16393 has been marked as a duplicate of this bug. ***
So the Mac folks "fixed" this is Mac OS X 10.5 Leopard, so all users must upgrade the OS! to fix a simple bug, that Opera does not have! Guess Opera does not use "NSURLConnection". Question why could they figure it out, and Webkit could/did not? This is unsatisfactory, in terms of how this bug was handled by both Apple and WEBKIT. If the OS must be upgraded then supply a patch that works without the OS upgrade. Since this will further delay the availability of this cookie functionality to MOST users. Is Apple trying to leverage this fix to "encourage" update/purchase of Leopard? Rather than supply a patch to OS X 10.4.10. How lame is that? Wonder if this kind of thing will make to an Apple TV ad. Only been a problem since 01/02/2006 !!! How can one encourage the use of this environment with this kind of example of how problems are handled with the DEFAULT browser on the MAC. Perhaps you could hire an Opera consultant. You have further justified why we reprogrammed out application to Windows/IE six months ago. RESOLVED/INVALID !! Balderdash!
(In reply to comment #24) > [...] RESOLVED/INVALID !! Balderdash! This particular bug was marked RESOLVED/INVALID because the bug isn't in WebKit itself, it's in a lower-level framework. This is the process we follow for bugs reported in Bugzilla that can't be fixed in WebKit. Note that the issue in the lower-level framework is being tracked/was tracked in Radar, Apple's internal bug-reporting tool.
>This particular bug was marked RESOLVED/INVALID because the bug isn't in WebKit >itself, it's in a lower-level framework. This is the process we follow for >bugs reported in Bugzilla that can't be fixed in WebKit. Note that the issue >in the lower-level framework is being tracked/was tracked in Radar, Apple's >internal bug-reporting tool. I recieved the above in response to my tirade re: this bug. So "NOT MY PROBLEM" is not a responsible position when the bug restricts important functionality available to WEBKIT. It clearly was not escalated in anyone's RADAR or it would have been fixed in less than 11 months, without requiring an OS upgrade! Someone needs a BIG PICTURE upgrade.