feat: add support for headers config #200
Conversation
serhalp
force-pushed
the
serhalp/frb-1835-support-headers-config
branch
3 times, most recently
from
0e08454 to
ff08f9a
Compare
serhalp
changed the title
serhalp
force-pushed
the
serhalp/frb-1835-support-headers-config
branch
2 times, most recently
from
8d6189e to
ccf12b1
Compare
| "description": "TypeScript implementation of Netlify's headers engine", | ||
| "type": "module", | ||
| "engines": { | ||
| "node": "^18.14.0 || >=20" |
serhalp
force-pushed
the
serhalp/frb-1835-support-headers-config
branch
2 times, most recently
from
b0d4959 to
b881f9f
Compare
serhalp
force-pushed
the
serhalp/frb-1835-support-headers-config
branch
from
b881f9f to
1f877fe
Compare
serhalp
force-pushed
the
serhalp/frb-1835-support-headers-config
branch
from
1f877fe to
4db3200
Compare
packages/dev/package.json
Outdated
| @@ -57,6 +57,7 @@ | |||
| "@netlify/config": "^23.0.4", | |||
| "@netlify/dev-utils": "2.2.0", | |||
| "@netlify/functions": "3.1.9", | |||
| "@netlify/headers": "^0.0.0", | |||
There was a problem hiding this comment.
I think we want to pin an exact version here.
There was a problem hiding this comment.
I'll make that change for internal consistency, but what are we solving for here and how do we plan to enforce it?
There was a problem hiding this comment.
When referencing packages from the monorepo, we always know the exact version we want to use. We're not enforcing that anywhere.
There was a problem hiding this comment.
Bleh, I wish npm workspaces had better functionality here. With pnpm or yarn we would just use workspace:*. 🤷🏼
| const matchingHeaderRules = headersForPath(headerRules, new URL(request.url).pathname) | ||
|
|
||
| for (const [key, value] of Object.entries(matchingHeaderRules)) { | ||
| response.headers.set(key, value) |
There was a problem hiding this comment.
This won't work for any responses with immutable headers. For example:
> Response.redirect("https://example.com").headers.set("X-Foo", "bar")
Uncaught TypeError: immutable
at _Headers.set (node:internal/deps/undici/undici:8609:17)
There was a problem hiding this comment.
Interesting. Wouldn't this never apply here though? We only ever apply header rules to static files.
Are you suggesting we implement the guard as a failsafe?
There was a problem hiding this comment.
Hmm, good point. It wouldn't hurt to have it as a failsafe, but not critical.
Summary
This adds support for static response headers configuration: https://docs.netlify.com/routing/headers/.
This is largely ported from analogous code in Netlify CLI. As noted here (private link), this does avoid porting over a bug I noticed.