Fetch API does not respect --allow-file-access-from-files (even though XHR does)
Reported by
james.br...@gmail.com,
Feb 8 2018
|
|||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/64.0.3282.119 Chrome/64.0.3282.119 Safari/537.36 Steps to reproduce the problem: 1. Load the test case in a recent Firefox release. Observe successful read of local file via both fetch and XHR. 2. Load the test case in "normal" Chromium / Chrome. Observe that both cases fail. (This has made a lot of people very angry and been widely regarded as a bad move, but is not the subject of this ticket.) 3. Load the test case in Chromium / Chrome with the "--allow-file-access-from-files" switch. Observe that XHR succeeds while fetch fails. What is the expected behavior? In no situation should XHR succeed while fetch fails (or vice versa). What went wrong? The Fetch spec says (https://fetch.spec.whatwg.org/#basic-fetch) that the file:// scheme is "left as an exercise for the reader" but Firefox (at least) has implemented it and it works in XHR, with the appropriate command-line switch. Did this work before? No Does this work in other browsers? Yes Chrome version: 64.0.3282.119 Channel: stable OS Version: Ubuntu 16.04 Flash Version: This prevents pages that need to load content from a relative URL from using fetch to do so -- you can't deploy the same code to be served over HTTP(S) or from a local file. I would contend that the entire point of the fetch API is that XHR is ugly and unwieldy, so having to check the scheme of the URL you're requesting and fall back on the older API "just in case" is a terrible workaround. If XHR can do it today, fetch should be able to as well.
,
Feb 9 2018
Able to reproduce the issue on reported chrome version 64.0.3282.119 and on the latest chrome version 66.0.3343.0 using Ubuntu 14.04. As the issue is seen from M60(60.0.3072.0) considering it as non-regression and marking it as Untriaged. Note: This issue is specific to Linux, seen different behaviour in Windows-10 and Mac 10.12.6. Thanks!
,
Feb 9 2018
,
Feb 10 2018
re c2, I tested in Chrome (not Chromium, unsure if that matters) on Win10, and I do see the same behavior I described in Linux. Are you sure you're running #3 with the "--allow-file-access-from-files" switch? If so, what result do you see when running the test case? Does fetch complete successfully?
,
Feb 10 2018
(If it matters, this is Win10, Google-branded Chrome 64.0.3282.140)
,
Feb 16 2018
This is a feature request, and I guess I can implement it, though I have some points I want to clarify before implementing. - Should we (blink developers) seriously care about features working only with --allow-file-access-from-files? - Is there any security risks to simply allow it? - Do we need an intent-to-ship for such a feature? jochen@, mkwst@, can you answer these questions? Thank you!
,
Feb 16 2018
I can answer question #1: as of this writing, at least 1432 people cared about local file system interaction enough to star https://bugs.chromium.org/p/chromium/issues/detail?id=47416 . I asked about this here because I was under the impression that the motivation behind the Fetch API was to be a modernized, drop-in replacement for the times and places you'd normally use XHR. If Fetch ("sometimes") can't do something that XHR can, then we're back to the bad old days of doing browser / feature detection and writing fallbacks to ensure cross-browser compatibility. |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by ajha@chromium.org
, Feb 9 2018