TypeError: Can't modify immutable headers. in Cloudflare Pages after updating to 4.16.1

[nicbovee]

Astro Info

Astro                    v4.16.1
Node                     v20.16.0
System                   macOS (arm64)
Package Manager          pnpm
Output                   hybrid
Adapter                  @astrojs/cloudflare
Integrations             @astrojs/react
                         @astrojs/svelte
                         @astrojs/tailwind
                         @sanity/astro
                         @sentry/astro

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

After building with 4.16.1 my site running on Cloudflare Pages in hybrid mode 500's on all non-prerendered routes.

Looking at the realtime logs I see complaints about headers:

18:17:35 [ERROR] TypeError: Can't modify immutable headers.\n    at setOriginHeader (chunks/index_CUH8Sv5d.mjs:1356:19)\n    at RenderContext.create (chunks/index_CUH8Sv5d.mjs:1393:5)\n    at async App.render (chunks/_@astrojs-ssr-adapter_BtNH5sZC.mjs:824:29)\n    at async Object.fetch (chunks/_@astrojs-ssr-adapter_BtNH5sZC.mjs:1016:22)

In the build output there's also a bunch of warnings now that hadn't been there up to this point:

11:28:16.727	18:28:16   ├─ /daily-readings/it-must-be-small/index.html18:28:16 [WARN] `Astro.request.headers` is unavailable in "static" output mode, and in prerendered pages within "hybrid" and "server" output modes. If you need access to request headers, make sure that `output` is configured as either `"server"` or `output: "hybrid"` in your config file, and that the page accessing the headers is rendered on-demand.
11:28:16.731	 (+4ms)

Locking the version to 4.16.0 and re-deploying fixed it.

What's the expected result?

I would expect these routes to work.

Link to Minimal Reproducible Example

https://hotfix-hide-entire-countdown.wildatheart1.pages.dev/the-series

Participation

• I am willing to submit a pull request for this issue.

[nicbovee]

Possibly caused by this change:
2d10de5#diff-153aea9d29dc6f65b7f594f4674159c48939a8402408a2e11742275c19c3dc94R86

[nicbovee]

Wondering if this should change to:

export function setOriginHeader(request: Request, pathname: string): void {
	request.headers.append(ASTRO_ORIGIN_HEADER, encodeURIComponent(pathname));
}

I'm missing context around this, but it looks like X-Astro-Origin is a new header when setOriginHeader is called, which makes me think .append is the right method to use based on these docs from cloudflare.

[JusticeMatthew]

I feel like set should be fine here after doing a bit of digging

This might be a bit above my skill level but to me it seems the issue would be caused by not duplicating the request in that utility function first (so it’s mutable), modifying it, and returning the modified request

I could be way off base though

[ammi1378]

I had the same issue, downgrading to [email protected] fixed it.

[jahands]

I feel like set should be fine here after doing a bit of digging

This might be a bit above my skill level but to me it seems the issue would be caused by not duplicating the request in that utility function first (so it’s mutable), modifying it, and returning the modified request

I could be way off base though

This is correct - in Cloudflare Pages / Workers, the request must be duplicated to make it mutable:

async fetch(request, env, ctx) {
	request.headers.set('x-foo', 'bar') // FAIL

	// Duplicate request to make it mutable
	const req = new Request(request)
	req.headers.set('x-foo', 'bar') // WORKS!

	return new Response('hello world')
},

Playground demo

[bluwy]

Sorry for the inconvenience everyone. For now I'd suggested pinning Astro to 4.16.0 to workaround this:

{
  "dependencies": {
    "astro": "4.16.0"
  }
}

We'll likely only able to get to fixing this next Monday, but I'll check with the team if we should revert #12173 for now, which seems to be the cause here.