Standardize fetch calls to `file:` URLs

[aduh95]

The WHATWG Fetch spec says this regarding fetching of URLs using the file: protocol:

For now, unfortunate as it is, file URLs are left as an exercise for the reader.

When in doubt, return a network error.

That'd be nice to have a standard way for handling those.

[lucacasonato]

I agree. I think this should be a normative optional extension of whatever work we do here, because some runtimes (Node) may not want to enable file: fetching at all.

The main topics I think need to be covered:

• All request methods other than "GET" should throw.
• Is content-type set on response bodies? I'd argue for no.
• Do files that are not found result in a "network error" (promise rejection), or a 404? I would argue for the former.
• Same as above, but for all other errors (not-a-file errors, read errors etc).
• Is content-length set on response bodies? I'd argue for no.

Notes on Deno's implemenation of file: fetching: https://deno.land/manual/runtime/web_platform_apis#fetching-local-files

[jimmywarting]

Having built a CORS proxy server myself using the fetch api then i would argue that i wouldn't at least want to allow the user to fetch local files and doing something like: https://cors.io/url=file://etc/psw so i have always been against it for security issues. browser dose not allow doing ajax calls on file:// either.

if i would want to read files from the file system then i would have used the file system api. if i would like to turn it into a Response object then i would probably do something like: new Response(await fs.openAsBlob(path)).text()

---

outdate - About getting Files from fs - Resolved (but not in Deno)

but i would rather want to have something like: `new Response(fs.fileFrom(path))` that way `content-length` & `content-type` would be added as a header (as fetch could understand this parts from `file.size` & `file.type` Gettings files from the filesystem is also an important feature that I wish to exist if you ever wish to upload a file togheter with FormData. That was half of the reason why I wanted to get https://github.com/denoland/deno/pull/10969 landed in Deno so that we eventually could have some way of gettings files from the file system and adding it into FormData and `new Response(blob)` and so that we could read files using the standard `file.stream(), file.arrayBuffer(), file.text()`

btw, there is also the possibility of fetch(URL.createObjectURL(blob))

[aduh95]

For reference, Node.JS landing an implementation of fetch that doesn’t support file: URLs has broken emscripten: https://github.com/emscripten-core/emscripten/pull/16917

[guest271314]

This worked briefly in node v22.0.0-nightly202311151d8483e713

>  var scriptText = await (await fetch("file:///home/user/exports.js")).text();
undefined
> scriptText
"const fn = () => 123;\nexport {fn};"
> const mod = await import(URL.createObjectURL(new Blob([scriptText], {type:"text/javascript"})));
undefined
> mod
[Module: null prototype] { fn: [Function: fn] }
> mod.fn()
123

then stopped working in node v22.0.0-nightly202311250bb5d88871.

Using file: protocol with fetch() is possible on Chromium-based browsers in an extension Issue 1227761: Fetch() should support file scheme for extensions

{
  "name": "Service Worker-based background script",
  "description": "Test that fetching a file scheme URL succeeds",
  "version": "1",
  "manifest_version": 3,
  "host_permissions": ["file:///*"],
  "background": {"service_worker": "service_worker_background.js"}
}

and in Deno deno 1.38.3 (release, x86_64-unknown-linux-gnu).