fix(dev): apply headers from route rules for static assets

[peterthenelson]

🔗 Linked issue

#2749

❓ Type of change

• [ ] 📖 Documentation (updates to the documentation, readme, or JSdoc annotations)
• [x ] 🐞 Bug fix (a non-breaking change that fixes an issue)
• [ ] 👌 Enhancement (improving an existing functionality like performance)
• [ ] ✨ New feature (a non-breaking change that adds functionality)
• [ ] 🧹 Chore (updates to the build process or auxiliary tools and libraries)
• [ ] ⚠️ Breaking change (fix or feature that would cause existing functionality to 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 for routeRules runs in the reloadable worker (like the majority of the server logic), while the public asset serving happens locally in the app created in dev-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:

• This only applies the headers from 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.
• This redundantly sets the headers in cases where the dev server was already setting them (i.e., the non public assets). I considered a couple alternatives, but they would either require duplicating or inverting the URL-path-to-file-path logic from the "send" package (which is what "serve-static" uses).

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

• [x ] I have linked an issue or discussion.
• [ ] I have updated the documentation accordingly.

[peterthenelson]

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

[peterthenelson]

I had a followup question (see thread) before I make the requested changes.

[pi0]

Added tests, two issues:

• path passed inside middleware omits base /build/test.txt gets /test.txt therefore rules isn't matching. (we need to find solution)
• Currently, nitro has an implicit behavior that ignores maxAge of public assets in development mode which means this patch can cause behavior change (long term asset caches in dev). I am thinking for Nitro v2, we should avoid setting cache-control from route rules to avoid possible regression.

[prettypet2137]

@pi0 I'm using Nuxt 3.12.4 with Nitro 2.9.7 and I have also same issue as above. Can you please release this update? Thank you.

[pi0]

There is a clear description of the state: https://github.com/nitrojs/nitro/pull/2814#issuecomment-2463082441

[dataexcess]

is there an ETA on when this fix will be shipped? I would prefer not have to pin my nitro version to this branch. Plus Im using nuxt, so is that even possible? (I'm a noob)