User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.0.260.0 Safari/532.5 Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:22.214.171.124) Gecko/20091105 Foresight Linux/3.5 Firefox/3.5.5 If you load a webpage from a file:// URL (i.e. on the disk, not from a website) and try to submit an XmlHttpRequest that is cross-origin, the browser will (correctly) attempt to send a preflight OPTIONS request (or, if it's a simple cross-site request, the request itself). The problem is that the value of the HTTP header "Origin" is set to the string "null" (not the null value, or perhaps "file://" as WebKit does). Reproducible: Always Steps to Reproduce: 1. Download the attached HTML file (test.html) and run it. Actual Results: The value of the origin header is "null" (string). Expected Results: Expected either a blank header or "file://". Not sure which it should be as the specification doesn't indicate. For more information on Cross-Site Resource Sharing, see the W3C document. http://www.w3.org/TR/cors/
Created attachment 416927 [details] Simple HTML test Save this file and load it from a file:// URL (from disk) to reproduce the problem. It will contact PHP script (harmless) on my webserver (smerpology.org) to produce the results.
We are following the spec here. See http://www.w3.org/TR/cors/#origin-request-header
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INVALID
Ah, OK. I missed that part of the spec. However, there is still a problem. If the server returns a "null" value for Access-Control-Allow-Origin for either a preflight OPTIONS call or a simple CORS response, Mozilla-based browsers will fail to treat that as acceptable. In the case of an OPTIONS request, the preflight check is treated as a failure and no follow-on request is made. In the case of a simple CORS request, "null" is ignored and the server's response is thrown away. According to http://www.w3.org/TR/cors/#resource-sharing-check, this should still work (i.e. as long as the server returns a string that is a match for what was sent in Origin by the user agent, everything should be fine). Should I open a new bug on that?
Hmm.. the spec used to say that that wasn't allowed IIRC. You had to use "*". I would raise this with the webapps WG since I believe the spec is wrong here.
Jonas, I'll do a little research and get back to you. The last working draft that specified this was here, in 2008: http://www.w3.org/TR/2008/WD-access-control-20080214/#access2
You need to log in before you can comment on or make changes to this bug.