Last Comment Bug 533987 - Cross-Origin Resource Sharing: If pages is loaded from a file:// URI, Origin header is "null" (string)
: Cross-Origin Resource Sharing: If pages is loaded from a file:// URI, Origin ...
Product: Core
Classification: Components
Component: XML (show other bugs)
: unspecified
: x86_64 Linux
-- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Andrew Overholt [:overholt]
Depends on:
  Show dependency treegraph
Reported: 2009-12-10 10:05 PST by Scott Parkerson
Modified: 2009-12-10 13:17 PST (History)
2 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Simple HTML test (550 bytes, text/html)
2009-12-10 10:07 PST, Scott Parkerson
no flags Details

Description User image Scott Parkerson 2009-12-10 10:05:23 PST
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/ Safari/532.5
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: 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.
Comment 1 User image Scott Parkerson 2009-12-10 10:07:49 PST
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 ( to produce the results.
Comment 2 User image Jonas Sicking (:sicking) No longer reading bugmail consistently 2009-12-10 10:40:45 PST
We are following the spec here. See
Comment 3 User image Scott Parkerson 2009-12-10 13:01:13 PST
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, 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?
Comment 4 User image Jonas Sicking (:sicking) No longer reading bugmail consistently 2009-12-10 13:04:18 PST
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.
Comment 5 User image Scott Parkerson 2009-12-10 13:17:20 PST

I'll do a little research and get back to you.

The last working draft that specified this was here, in 2008:

Note You need to log in before you can comment on or make changes to this bug.