Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 65 users
Status: Duplicate
Merged: issue 47416
Owner: ----
Closed: Mar 23
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug-Regression



Sign in to add a comment
XHR using file: protocol not working.
Reported by imofftos...@gmail.com, Apr 10 2010 Back to list
Chrome Version       : 5.0.342.9 (Official Build 43360) beta
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 4: OK
  Firefox 3.x: OK
IE 7:
IE 8:

What steps will reproduce the problem?
1.  Create a file test.txt containing some text, eg 'OK'.
2.  Place bug.html (attached) in the same directory as test.text.
3.  Open bug.html as file:///<path to bug.html>/bug.html.
4.  View console.

What is the expected result?
response text: OK

What happens instead?
response text:  
Uncaught Error: NETWORK_ERR: XMLHttpRequest Exception 101

Please provide any additional information below. Attach a screenshot if
possible.

If the page is loaded through an http: uri, it works as expected.  Chrome 
has this problem on both Mac OS/X 10.6 and Ubuntu 9.04 (gdm).
 
bug.html
809 bytes Download
Maybe something to note here is that other browsers like Firefox now require XHR requests on the file system to 
be limited to subdirectories of the current HTML file (base URI), for security reasons.

However Chromes seems to block all XHR requests to file://, not only those leaving the current subdirectory, so 
XHR seems to simply not work at all for file:// URIs.
 Issue 45867  has been merged into this issue.
Labels: -Area-Undefined Area-Internals Internals-Network Internals-Plugins
Status: Available
Summary: XHR using file: and chrome-extension: protocols not working. (was: NULL)
This is caused by a recent tightening of security on the file:// protocol. This change has various undesirable side-effects which we're looking to change.

The same problem seems to affects XHR using "chrome-extension:", which breaks extensions: at http://code.google.com/chrome/extensions/xhr.html we explain how to use XHR to read settings from a file in an extension, which will currently not work :(.
See also  issue 47416 
We should probably put a not on http://code.google.com/chrome/extensions/xhr.html notifying developers of this problem before we get more reports.
*note
Labels: Documentation Feature-Extensions
Status: Assigned
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=51854 

------------------------------------------------------------------------
r51854 | kathyw@chromium.org | 2010-07-08 09:52:20 -0700 (Thu, 08 Jul 2010) | 6 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/static/xhr.html?r1=51854&r2=51853
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/extensions/docs/xhr.html?r1=51854&r2=51853

Add a note that the code sample is broken until the bug is fixed.

BUG= 41024 
TEST=none

Review URL: http://codereview.chromium.org/2880021
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=51855 

------------------------------------------------------------------------
r51855 | kathyw@chromium.org | 2010-07-08 09:54:49 -0700 (Thu, 08 Jul 2010) | 9 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/375/src/chrome/common/extensions/docs/static/xhr.html?r1=51855&r2=51854
   M http://src.chromium.org/viewvc/chrome/branches/375/src/chrome/common/extensions/docs/xhr.html?r1=51855&r2=51854

Merge 51854 - Add a note that the code sample is broken until the bug is fixed.

BUG= 41024 
TEST=none

Review URL: http://codereview.chromium.org/2880021

TBR=kathyw@chromium.org
Review URL: http://codereview.chromium.org/2931001
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=51856 

------------------------------------------------------------------------
r51856 | kathyw@chromium.org | 2010-07-08 09:56:13 -0700 (Thu, 08 Jul 2010) | 9 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/453/src/chrome/common/extensions/docs/static/xhr.html?r1=51856&r2=51855
   M http://src.chromium.org/viewvc/chrome/branches/453/src/chrome/common/extensions/docs/xhr.html?r1=51856&r2=51855

Merge 51854 - Add a note that the code sample is broken until the bug is fixed.

BUG= 41024 
TEST=none

Review URL: http://codereview.chromium.org/2880021

TBR=kathyw@chromium.org
Review URL: http://codereview.chromium.org/2906002
------------------------------------------------------------------------

The temporary note is in the doc now. Please reassign this bug to me once the note is no longer necessary.
Status: Available
I'm getting the same problem. It's not very nice, is it.

My work around for now is to load files using JSONP. Not very elegant, but fortunately for me was a quick win; I don't have much data to load.
Comment 14 by Deleted ...@, Jul 17 2010
A useful workaround on Linux or Mac, (or possibly with Python installed on windows) is to launch a console, cd to the target directory containing all your content and run...

python -m SimpleHTTPServer 8080

Which then means you can test designs which should eventually be served by a real remote webserver, but without having to set up a whole local webserver just for this. 

After launching the server visit http://localhost:8080 to navigate the directory that you launched it from. 

Using this strategy I've run into some MIME type silliness*. However, if you're using normal file extensions this shouldn't be a problem. 

* [XML documents with a .rng extension don't get served as text/xml, so XMLHTTPRequest tries to handle them as text instead of a DOM).]
Comment 15 by Deleted ...@, Jul 18 2010
Finally found lighttpd, which is a snap to install and provides an idiot proof config to launch a localhost webserver INCLUDING mime type control, as outlined here...
http://redmine.lighttpd.net/projects/lighttpd/wiki/TutorialConfiguration

A good workaround for issues with file:// uris.

Installable on Linux from distro repositories and Mac through darwinports...
http://lighttpd.darwinports.com/

Possible to run through Windows using Cygwin, but I wouldn't count this simple until there's a point and click installer for our Microsoft-licensed, GUI-driven friends.
Comment 16 by timof...@gmail.com, Aug 11 2010
I've read on the forums and blogs that people who began to port their projects to chrome, cancelled porting because of this issue. They are porting back to old good ff or ie.
Comment 17 Deleted
Comment 18 by r...@rbtec.net, Aug 11 2010
@timoffei - Yes. Chrome have also blocked any further comments to the main thread about this and merged all other related threads with that one. I expect they will also merge this one. Very arrogant attitude.

Unfortunately the issue has a status of 'Available' i.e. not being worked on so they clearly don't care.   

We have written to Eric Schmidt, CEO Google, about this but received no reply, which is rather impolite, and clearly no action is being taken.

Possibly a related topic - if you update Google Earth now it will automatically install Chrome even if you don't want it (would be nice to have the choice). Since then Google Earth throws an error when you try to e-mail a location (.kmz file). Earth cannot launch the e-mail client. I wonder if this is due to the file:// protocol block. Maybe they've shot themselves in the foot!! LOL 

Google's credibility is now zero here. 
From personal experience during development (see previous comments), I understand your frustration.

*However*, this issue tracker is not intended to be a forum for personal opinions on business conduct and bug priorities: the issue track is intended solely to contain and discuss technical details of a bug and its fix.

Your messages distract from that and you are making it harder and more time-consuming for developers to separate the wheat from the chaff. Please stop cluttering this issue with comments that do not contain any information a developer needs to understand and fix the issue, or we will have to close down the discussion on this bug too.

@skylined@chromium.org
Is there a reason for why it is not marked as a regression?
A lot of posts were posted in chromium-extensions asking to know the version of the extension and everyone kept telling them to get the manifest through XMLHttpRequest. Now that this is gone (and used to be working!), what else can they do?

This is a regression as any and it should have been handled appropriately. file:// URLs - I get it. Alright. A new security model. But chrome-extension:// URLs - no, no, no, this is irrational and a real regression.
Labels: Regression Mstone-X OS-All
@phistuck: flag added. Unfortunately, it's probably not easier to "fix" one and not the other, as the two are handled by the same code. I expect that a fix will need to include both protocols and will have to trade security and usability. That said, if a quick fix for chrome-extension:// turns out to be possible, we should implement it :).

Status: Untriaged
Status: Unconfirmed
I'm actually not seeing an error on Dev channel Linux when fetching an extension's manifest.json via XHR - see https://chrome.google.com/extensions/detail/mpibkgjmbbnchaoldblpbofalmlcmkdo for a proof of concept.

Has this been fixed for chrome-extension:// URLs or am I misunderstanding the bug?
Comment 25 by *mdu@chromium.org, Nov 11 2010
Confirmed happening with current Dev build 9.0.576.0 (Official Build 65344), with reporter's steps.

Chrome console shows error like:

XMLHttpRequest cannot load file:///C:/******/test.txt. Cross origin requests are only supported for HTTP.
response text:  
Uncaught Error: NETWORK_ERR: XMLHttpRequest Exception 101
Comment 26 by *mdu@chromium.org, Nov 11 2010
Status: Untriaged
Comment 27 by aa@chromium.org, Nov 11 2010
Status: Available
@skylined can you please describe what the fix is?
Comment 28 by itoma...@gmail.com, Nov 27 2010
any updates?
any good work-arounds so far?
@aa: I have no fix or work-around for XHR using file://. XHR using chrome-extensions:// is working for me on 7.0.517.44 Windows. It may have been fixed, but I do not know by whom and when.
@kathyw: can you remove the note from the extensions documentation as it seems to be working fine again?
Thanks!
Summary: XHR using file: protocol not working. (was: NULL)
Labels: -Feature-Extensions
I'm using 7.0.517.44 on Gentoo and access to chrome-extension:// still generates Error 101.
Labels: -Internals-Plugins Feature-Plugins
Labels: -Regression bulkmove Type-Regression
Chrome Version       : 5.0.342.9 (Official Build 43360) beta
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
     Safari 4: OK
  Firefox 3.x: OK
IE 7:
IE 8:

What steps will reproduce the problem?
1.  Create a file test.txt containing some text, eg 'OK'.
2.  Place bug.html (attached) in the same directory as test.text.
3.  Open bug.html as file:///&lt;path to bug.html&gt;/bug.html.
4.  View console.

What is the expected result?
response text: OK

What happens instead?
response text:  
Uncaught Error: NETWORK_ERR: XMLHttpRequest Exception 101

Please provide any additional information below. Attach a screenshot if
possible.

If the page is loaded through an http: uri, it works as expected.  Chrome 
has this problem on both Mac OS/X 10.6 and Ubuntu 9.04 (gdm).
I have a slightly different use case -- I'm not building a chrome extension, I'd just like to be able test my XHRs in the current/sub-directory.

I'm loading:
  file:///C:/home/epi/jslinux/index.html

And I get:
  XMLHttpRequest cannot load file:///C:/home/epi/jslinux/vmlinux-2.6.20.bin. Cross origin requests are only supported for HTTP.

It seems totally secure that, if you are loading a static piece of HTML from your local hard drive, that staic HTML should be able to access other static pieces of HTML in its current directory.
Project Member Comment 38 by bugdroid1@chromium.org, Mar 9 2013
Labels: -Area-Internals -Internals-Network -Feature-Plugins -Type-Regression Type-Bug-Regression Cr-Content-Plugins Cr-Internals Cr-Internals-Network
Project Member Comment 39 by bugdroid1@chromium.org, Apr 6 2013
Labels: Cr-Blink
Project Member Comment 40 by bugdroid1@chromium.org, Apr 6 2013
Labels: -Cr-Content-Plugins Cr-Internals-Plugins
Labels: -Cr-Internals-Network
Components: -Blink Blink>Network>XHR
 Issue 673179  has been merged into this issue.
Components: -Internals>Plugins -Internals Internals>Network
Mergedinto: 47416
Status: Duplicate
XHR is just exposing the underlying network level security behavior here which was tightened back in  issue 4197 .  Relaxing that is tracked in  issue 47416 
Sign in to add a comment