1484620 - xhr to local file using a relative url behaves differently on ubuntu and windows

Status: UNCONFIRMED

(Core :: DOM: Security, defect, P3)

Description

[sharun.msgs]

Attachment: ff-ubuntu-issue.zip

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36

Steps to reproduce:

I work on the kiwix (offline wikipedia reader) project. We use a XHR range request to read the first 80 bytes of our web archives (zim files) for metadata when app starts up.
No issues doing that for a couple of years now. Recently on ubuntu (18.04 firefox 61.0.1)  started seeing a Cross origin request blocked - CORS requests not http. 

Not seeing this error windows. After doing further testing it looks like on ubuntu the requests works if the file is in the same directory as source code but not wth a relative url. 
On windows am able to use relative paths to the same xhr request function and access the local file in a parent directory.    

steps to repro:
unzip attachment
test 1 -
open somedir/loadzim-moz.html...check console for success or error message
works on windows 
cors error on ubuntu

test 2 -
move the zim file into the directory with the html file 
change path in code i.e. params["archive"] = "wikipedia_en_ray_charles_2015-06.zim";
reopen html and look at console for error or sucess

works on both windows and ubuntu

Comment 1

[Matthias Versen [:Matti]]

I get the same cors error in the console on windows (at least with nightly builds) after the checkin from bug Bug 1442551.
Based on the comments in bug Bug 144255 it looks like the block request is intendent but i move this to the right component for a final decision.

Comment 2

[Masatoshi Kimura [:emk]]

Note that bug 144255 is very very old. IIRC we loosened XHR-to-file after that.

Comment 3

[Masatoshi Kimura [:emk]]

Hmm, the check flip-flops several times (bug 230606 and bug 402983). Currently only files in the same directory should be allowed.

Comment 4

[Masatoshi Kimura [:emk]]

But I can actually read files from subdirectories at least on Windows release (61.0.2)... Did it regress recently?

Comment 5

[Honza Bambas (:mayhemer)]

Testing on Windows 10 (current nightly, release) and Ubuntu 16.04 (update to 18.04 is pending) with Fx release 61.0.1, all preferences at their defaults, all gives me the same results for xhr with relative urls from file loaded html:

file in the same dir as the html: accessible
file in a subdir ("subdir/foo.txt"): accessible
file in an upper dir ("../foo.txt"): inaccessible (expected)

note that security.fileuri.strict_origin_policy is by default true.

I *think* we fail from some reason the relaxation check at:
https://searchfox.org/mozilla-central/rev/71ef4447db179639be9eff4471f32a95423962d7/caps/ContentPrincipal.cpp#311

Probably one of the checks fails at:
https://searchfox.org/mozilla-central/rev/71ef4447db179639be9eff4471f32a95423962d7/netwerk/base/nsNetUtil.cpp#2627,2661,2695

...that is the only thing that comes to my mind being platform dependent.

Comment 6

[Daniel Veditz [:dveditz]]

XHR can only read from the same origin unless there's CORS. In other browsers all file: have a different origin and only http supports CORS so you effectively can't do what you're trying to do. Firefox has a bit of an exception in allowing the same directory or sub-directories currently, although we're wanting to tighten that up to match Chrome eventually which again will break this usecase.

You'll have to eventually run a local web server to do this, or perhaps write an extension which can read files even though web pages cannot.

Comment 7

[Masatoshi Kimura [:emk]]

(In reply to Daniel Veditz [:dveditz] from comment #6)
> You'll have to eventually run a local web server to do this, or perhaps
> write an extension which can read files even though web pages cannot.

IIRC WebExtensions is not allowed to read arbitrary files.

Comment 8

[sharun.msgs]

(In reply to Daniel Veditz [:dveditz] from comment #6)
> XHR can only read from the same origin unless there's CORS. In other
> browsers all file: have a different origin and only http supports CORS so
> you effectively can't do what you're trying to do. Firefox has a bit of an
> exception in allowing the same directory or sub-directories currently,
> although we're wanting to tighten that up to match Chrome eventually which
> again will break this usecase.
> 
> You'll have to eventually run a local web server to do this, or perhaps
> write an extension which can read files even though web pages cannot.

Thanks for the clarity on this. Have been waiting for a while to see which way the wind would blow :) 
Will work around it.
  
Just a related side note, offline web archive files (from wikipedia/stackoverflow/khanacademy/ted/dash/zeal etc etc) are a natural fit for browsers to handle. What else is better at dealing with web content? XHR to local file, allowed us to avoid asking the user to keep reusing the fileselector to open the file every session (as we can't maintain the FILE object across sessions). XHR to file:// was the alternate. What has happened from lack of clarity on xhr to file:// (also see 1378228) is we end up building/supporting two dozen different platform specific apps/webapps/extensions/server based solutions which are all devoted to basically rebuilding basic browser features within an app like context most of the time in some half baked rendering, link breaking manner. But so it goes...
 
Google probably has no great incentive to support offline access of large searchable local archives, but I hope Mozilla is thinking about this stuff. With the dirt cheap availability of hard drives/sdcards these days, archived web content for offline access is growing fast and Firefox has an opportunity here to really simplify the whole story. 

Thanks to all for the quick response!