Standardize fetch calls to file: URLs #5

Activity

1. lucacasonato commented on May 17, 2022

   

   lucacasonato

   on May 17, 2022

   Member

   More actions

   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

   👍React with 👍2Reacted by Antoine du Hamel and Owen Buckley
2. jimmywarting commented on Jun 14, 2022

   

   jimmywarting

   on Jun 14, 2022

   Last edited by jimmywarting

   More actions

   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))

   👍React with 👍3Reacted by Antoine du Hamel, Jimmy Wärting and Parbez

   👀React with 👀1Reacted by exoticknight
3. aduh95 commented on Jun 15, 2022

   

   aduh95

   on Jun 15, 2022

   Author

   More actions

   For reference, Node.JS landing an implementation of fetch that doesn’t support file: URLs has broken emscripten: emscripten-core/emscripten#16917
4. Ethan-Arrowood

   transferred this issue fromon Jan 19, 2023
5. guest271314 commented on Nov 25, 2023

   

   guest271314

   on Nov 25, 2023

   More actions

   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).