-
Notifications
You must be signed in to change notification settings - Fork 533
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
fix(dev): apply headers from route rules for static assets #2814
base: v2
Are you sure you want to change the base?
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 :) |
routeRules
in dev serverrouteRules
in dev server
routeRules
in dev server
I had a followup question (see thread) before I make the requested changes. |
Added tests, two issues:
|
@pi0 |
There is a clear description of the state: #2814 (comment) |
π Linked issue
#2749
β Type of change
π Description
As detailed in the linked bug,
routeRules
fail to apply to public assets when using the dev server. The reason this happens is, IIUC, that the handler forrouteRules
runs 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