You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
In many frontend projects I've worked on, I've started relying on ``Sec-Fetch-Modeand/orSec-Fetch-Dest` headers. Because it's very common to return `/index.html` for SPA apps, but returning it for CSS/JS and other unrelated static resources is annoying. Therefore it's very helpful to check that the current request is a `navigate` to `document` before returning `/index.html`, otherwise 404.
Would PR's adding the below be accepted, or does new API's require discussion first in issues?
Describe the solution you'd like
It would be great if the Sec-Fetch-* headers were just included in HEADERS from jsr:@std/http@1/unstable-header. It would be even more awesome if there was a dedicated API for this, like with accepts in negotiation.ts:
There current code is not terrible, but using type-safe header values and type safe possible header values means it's easy to for instance misspell 'navigate' to 'navigation'.
Perhaps all Sec-Fetch-* params could be combined in one function? Not sure about the best name, but it would probably be very handy if all of these could be provided at once. The mode, dest & site props could take a string or string[], and have a union type of all acceptet string types.
Is your feature request related to a problem? Please describe.
In many frontend projects I've worked on, I've started relying on ``Sec-Fetch-Mode
and/or
Sec-Fetch-Dest` headers. Because it's very common to return `/index.html` for SPA apps, but returning it for CSS/JS and other unrelated static resources is annoying. Therefore it's very helpful to check that the current request is a `navigate` to `document` before returning `/index.html`, otherwise 404.I don't know why this header is not included in https://www.iana.org/assignments/http-fields/http-fields.xhtml#field-names, but these headers were part of Baseline 2023, and are supported in all major browsers currently.
Would PR's adding the below be accepted, or does new API's require discussion first in issues?
Describe the solution you'd like
It would be great if the
Sec-Fetch-*
headers were just included inHEADERS
fromjsr:@std/http@1/unstable-header
. It would be even more awesome if there was a dedicated API for this, like withaccepts
in negotiation.ts:The biggest win for this being able to write the values above in a type safe way:
Describe alternatives you've considered
There current code is not terrible, but using type-safe header values and type safe possible header values means it's easy to for instance misspell
'navigate'
to'navigation'
.The text was updated successfully, but these errors were encountered: