Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should fetching local files always results in a TypeError? #186

Closed
presstube opened this issue Aug 1, 2015 · 8 comments
Closed

Should fetching local files always results in a TypeError? #186

presstube opened this issue Aug 1, 2015 · 8 comments

Comments

@presstube
Copy link

Hi there,

When loading local files I bump into TypeError: Network request failed right away due to the response.status of local requests being 0, thus getting rejected by fetch's initial status handling.

In the README I see the portion on Handling HTTP error statuses, but that would only work if fetch's initial xhr.onload didn't reject with a TypeError first.

Would it be reasonable to change fetch's initial status handling to something like this so that local fetches could make it through?

if ((status !== 0 && status < 100) || status > 599) {
    reject(new TypeError('Network request failed'))
    return
}

For context. I'm working on a project in which the same codebase runs:

  1. In Browser, loading local files via a local dev server (no problems here)
  2. Ejecta in iOS, loading purely local files (which is where I'm getting my status === 0)

Thanks!

@mislav
Copy link
Contributor

mislav commented Aug 3, 2015

I would be down to treating 0 status as success but only if the URL scheme was file:. How does native fetch implemented in Chrome and Firefox behave with regard to local files?

@presstube
Copy link
Author

I took a look and it turns out that the native implementations of fetch don't like loading local files either.

Chrome:

Fetch API cannot load file:///Users/someuser/someproject/some-local-file.json. URL scheme "file" is not supported.

Firefox (only when I explicitly catch, otherwise it's silent)

TypeError: NetworkError when attempting to fetch resource.

@dgraham
Copy link
Contributor

dgraham commented Feb 4, 2016

Closing because the polyfill behaves the same as native browser implementations when loading local files.

@dgraham dgraham closed this as completed Feb 4, 2016
@mislav
Copy link
Contributor

mislav commented Feb 4, 2016

the polyfill behaves the same as native browser implementations when loading local files.

I don't think that's true. I think our polyfill allows loading local files, but native implementations don't.

@dgraham
Copy link
Contributor

dgraham commented Feb 4, 2016

The following rejects with an Error in Chrome, Firefox, and the polyfill.

fetch('file:///tmp/test.txt').catch(function(e) { console.log(e) })

Is something else being requested in this issue? I may be misunderstanding it.

@mislav
Copy link
Contributor

mislav commented Feb 4, 2016

This code works on Safari when test html is loaded via file: protocol:

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>Fetch Tests</title>
</head>
<body>
  <script>
    nativeFetch = window.fetch
    window.fetch = undefined
  </script>
  <script src="../fetch.js"></script>
  <script>
    fetch('../package.json')
      .then(function(res){ return res.text() })
      .then(function(text){ console.log('polyfill', text) })
  </script>
</body>
</html>

@mislav
Copy link
Contributor

mislav commented Feb 4, 2016

Even though Safari allows XMLHttpRequest using the file: protocol (and we do nothing in the polyfill to prevent it), Chrome and Firefox access restrictions disallow it. Still, the error thrown as a result of that XHR restriction doesn't match the TypeError thrown when native fetch is used.

But, we might not want to care about this mismatch. "Fixing" the type of the error thrown would be too much work since detecting file: protocol URLs may be tricky.

@LMLB
Copy link

LMLB commented Apr 16, 2016

Firefox does allow XMLHttpRequest and Fetch on local files if the page is a local file and and the requested file is in the same directory (or any number of subdirectories) relative to the page.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants