Bug 16357 – XMLHttpRequest.setRequestHeader("Cookie","") does not work correctly

• Status: RESOLVED
• Resolution: INVALID
• Component: XML

[Andreas Amann]

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.

[Andreas Amann]

Created attachment 17790 [details]
Test case (setting empty cookie does not work)

[David Kilzer (:ddkilzer)]

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)?

[Andreas Amann]

(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 :-(

[Mark Rowe (bdash)]

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.

[Andreas Amann]

(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...)

[Alexey Proskuryakov]

(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!

[Andreas Amann]

(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

[Alexey Proskuryakov]

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.

[Alexey Proskuryakov]

...not only we could, but this is already so.

[Stu Charlton]

(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

[Alexey Proskuryakov]

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.