fix(dev): apply headers from route rules for static assets #2814
Conversation
- These otherwise fail to be applied to public assets (see nitrojs#2749). - This change replies them redundantly in the other cases (where they were already being applied), but the alternative would require duplicating or reversing the URL / file path logic from the "send" package. fixes nitrojs#2749
- Using nitro so that I can use the dev servers for local development and testing of the CSPs, and then it should make Cloudflare Pages deployments pretty easy. - Unfortunately I had to fix a bug in the nitro dev server; hopefully I can get nitrojs/nitro#2814 merged (or another approach to fixing it if the maintainers don't like that one). - Added functionality to run 3p scripts (you can test that this works by using the fake3p server--see README.md). - I think current version of CSPs has the properties I want, but I might need to change them when adding WASM.
|
@pi0 let me know if there's anything else I should do before you review this. Also, thanks for all your work on the many unjs projects; I've been finding them really useful :) |
pi0
changed the title
routeRules in dev serverrouteRules in dev server
pi0
changed the title
routeRules in dev server
| createRadixRouter({ routes: nitro.options.routeRules }) | ||
| ); | ||
| app.use( | ||
| "/", |
There was a problem hiding this comment.
I think we could add middleware only to static asset paths (and ideally only when matching them)
There was a problem hiding this comment.
Before I opened the PR, I had thought through two different possible ways to do this that I wasn't super satisfied with:
-
serveStatic can optionally take a setHeaders callback. Unfortunately, the "path" argument it passes the callback is the file path, not the URL path, so you have to reverse that transformation (including os-specific separators and whatnot) before running it through the radix router.
-
The middleware could run on "/" but then check if a file exists in the public assets dir before applying the other logic. This requires duplicating the (forward) transformation that the "serve" package preforms (URL -> file path).
Maybe I'm missing an easier approach, or maybe not. Anyhow, let me know which option you'd prefer I pursue.
|
I had a followup question (see thread) before I make the requested changes. |
🔗 Linked issue
#2749
❓ Type of change
📚 Description
As detailed in the linked bug,
routeRulesfail to apply to public assets when using the dev server. The reason this happens is, IIUC, that the handler forrouteRulesruns in the reloadable worker (like the majority of the server logic), while the public asset serving happens locally in the app created indev-server/server.ts. Requests for public assets get served without ever proxying anything to the worker.I solve this by adding a handler to the dev server itself that partially duplicates some of the logic in
route-rules.ts. Some notes:routeRules. The actual handler in the worker also allows for redirects and proxying. It's not clear to me whether it makes any sense to apply those to public assets, and in the case of proxying, it requires the "localFetch" object.Anyway, it's totally possible I'm going about this the wrong way, but that's my reasoning for why I did it this way.
Resolves #2749
📝 Checklist