fix: corsify issue "can't modify immutable headers"

[nicolasvienot]

Description

A fix was implemented in 74f63ab to clone the response in corsify in order to avoid this error:

{
  "status": 500,
  "error": "Can't modify immutable headers."
}

Unfortunately, it seems not to be enough, and we're still having the issue with Cloudflare when a response is modified by corsify. A solution we found and implemented is to recreate a response by using new Response(...).

Applying the fix here.

Related Issue

Link to the related issue: related to #242

Type of Change (select one and follow subtasks)

• Bug fix (non-breaking change which fixes an issue)

[nicolasvienot]

I can open a new issue if needed, please let me know 👍
it might also be related to: #249

[kwhitley]

Thanks @nicolasvienot - can you give me minimal repro steps to see this immutable headers issue on a Worker? I use CORS on virtually all my Workers (which is what I exclusively develop on these days) and am not running into this...

I'd like to ensure this is absolutely necessary before adding so many bytes! :)

[aonnikov]

@kwhitley I think you can use this sample to reproduce the issue:

import { Router, cors } from 'itty-router'

const router = Router({
  before: [preflight],
  finally: [corsify]
})

router.get('/sample', ({ params }) => {
  const cache = caches.default
  const cached = await cache.match(request)
  if (cached !== undefined) {
    return cached
  }

  const response = new Response(null, { status: 200 })
  ctx.waitUntil(cache.put(request, response.clone()))

  return response
})

return await router.fetch(request).catch(error)

When you access the first time, it returns 200, but the next requests will return 500 error.

{
  "status": 500,
  "error": "Can't modify immutable headers."
}

And there will be a warning message in worker logs:

A ReadableStream branch was created but never consumed. Such branches can be created, for instance, by calling the tee() method on a ReadableStream, or by calling the clone() method on a Request or Response object. If a branch is created but never consumed, it can force the runtime to buffer the entire body of the stream in memory, which may cause the Worker to exceed its memory limit and be terminated. To avoid this, ensure that all branches created are consumed.

 * Unused stream created:
    at corsify (file:///.../temp/node_modules/.pnpm/[email protected]/node_modules/src/src/cors.ts:81:44)

[marcelgerber]

Hi @kwhitley! If it helps, I'm running into the same issue, and this fix indeed helps fix it :)

[DarkLite1]

Is this already implemented?

[arcanis]

@kwhitley this is still an issue; also see this thread from the Cloudflare forum explaining why you can't set headers on a cloned response: https://community.cloudflare.com/t/whats-the-point-of-response-clone/216456

[arcanis]

Although I think I see why you might not be experiencing it - there's a segment of code that doesn't add the header if it's already there. So if you cached the answer post-cors (for example by adding your cache as a middleware) it might work; in the OP the cache is performed within the handler, so the response object is not longer mutable.