denoland
feat(http): Add --no-cache option to file_server
I use file_server with the Resource Override browser extension to make local edits to web apps before deploying changes. The one pain point with this combo is that my browser is adamant about caching every response it gets from it, even when I tick the Disable Cache option in the browser's dev tools. So, I thought I'd add an option to file_server to tell the client not to cache any responses. My issue is fixed! Hopefully others find it useful too 😊
I feel the issue is too specific to that browser extension.
The one pain point with this combo is that my browser is adamant about caching every response it gets from it, even when I tick the Disable Cache option in the browser's dev tools.
Why does that extension ignore Disable Cache option? I feel the above situation is the issue of the browser extension, not the server.
I checked my scenario using the latest file_server.ts with Resource Override while ticking Disable Cache in my browser dev tools, and I found that the extension did indeed honor the setting. So I'm not sure what was causing the issue to begin with.
My original thought for this feature was inspired by http-server for Node.js, which has a -c option:
Set cache time (in seconds) for cache-control max-age header, e.g.
-c10for 10 seconds. To disable caching, use-c-1.
Maybe my issue came from first using http-server in my workflow, and then switching to file_server. (because I prefer Deno 😀) It looks like http-server by default applies the response header cache-control: max-age=3600, and that might have caused issues for people using the app as a development server.
I do think there's value in enabling users to configure cache settings. What do you think?
I think there is value in supporting something like http-server's -c option. I think we should support setting the cache time though, and not just turning it on/off.
Really hoping for a -c option. If @plohm12 doesn't want to pick it up, I'd love to.
@plohm12 do you want to push on this? If not, I'd be game to pick it up.
Hey @lino-levan, you can take it over. I don't think I'll get around to it anytime soon. Thanks!
@iuioiua Yup, closing (without merge) in favor of #2977
@plohm12 Thanks for your suggestion anyway