Cookies specified by an XMLHttpRequest using setRequestHeader() are not being sent properly. Instead, the request uses the cookie jar and sends the cookies stored in Safari. This makes it impossible to use multiple logins (e.g., for Dashboard widgets) to a site or explicitly sending an empty header and requires login through Safari for widgets connecting to cookie-based login sites. See attached test case detailed instructions on how to reproduce this bug and check the actual headers being sent by the request.
Created attachment 17790 [details] Test case (setting empty cookie does not work)
See Bug 16325 and r28515: http://trac.webkit.org/projects/webkit/changeset/28515 To clear a cookie properly, I believe you need to set the same cookie name with a date in the past. Does this work on other browsers (like MSIE or Firefox)?
(In reply to comment #2) > Does this work on other browsers (like MSIE or Firefox)? It used to work in Safari 2.0.x (and Dashboard in 10.4.x) - the problem is not just setting an empty cookie does not work but even setting XMLHttpRequest.setRequestHeader("Cookie","test=1234") will result in only the cookies from Safari being sent, the "test" cookie is nowhere to be found in the request being sent. Firefox did not allow the request to be sent due to some security issue :-(
Reporter had filed this in Radar as <rdar://problem/5567386>. Commentary in the Radar shows that this issue is below WebKit in the CFNetwork layer. I'm going close this bug as INVALID as the issue here is not inside WebKit.
(In reply to comment #4) > Reporter had filed this in Radar as <rdar://problem/5567386>. Commentary in > the Radar shows that this issue is below WebKit in the CFNetwork layer. Sorry about the dupe submission - I don't see any activity for the bug submitted to Radar. It would be extremely useful if submitters would see comments on bugs they submitted - currently submitting a bug is pretty much a black hole (unless they come back as duplicates which makes things even worse...)
(In reply to comment #5) > Sorry about the dupe submission It is perfectly OK and even helpful to file bugs in both places. It helps to cross-reference them, though. (In reply to comment #3) > Firefox did not allow the request to be sent due to some security issue :-( So, does Firefox disallow setting the Cookie header for security reasons? We may want to block that more thoroughly than via a CFNetwork quirk then!
(In reply to comment #6) > So, does Firefox disallow setting the Cookie header for security reasons? We > may want to block that more thoroughly than via a CFNetwork quirk then! No, Firefox disallows sending a non-local XMLHttpRequest from an HTML file loaded via the file:// protocol. This can be overwritten using netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserRead"); though (without any notification to the user): http://www.mozilla.org/projects/security/components/signed-scripts.html
Please note that the XMLHttpRequest spec now forbids setting the Cookie header, citing security reasons. We could have local files exempt from this limitation though.
...not only we could, but this is already so.
(In reply to comment #8) > Please note that the XMLHttpRequest spec now forbids setting the Cookie header, > citing security reasons. We could have local files exempt from this limitation > though. > Where in the spec is this? http://www.w3.org/TR/XMLHttpRequest/ doesn't say anything of the sort
A newer version of the draft is available at <http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/Overview.html?content-type=text/html;%20charset=utf-8>. This requirement is in setRequestHeader description.