createCors().corsify eats additional Set-Cookie headers

[etinquis]

Describe the Issue

When calling corsify on a response with multiple Set-Cookie headers, only one will be preserved.

Example Router Code

console.log('before', resp.headers.getSetCookie()); // has multiple cookies
const corsResp = cors.corsify(resp);
console.log('after', corsResp.headers.getSetCookie()); // has a single cookie

Expected Behavior

All Set-Cookie headers (and maybe any other duplicate headers?) should be preserved.

Actual Behavior

Only one Set-Cookie header is kept in the resulting response.

Environment (please complete the following information):

• Environment: Cloudflare Workers
• itty-router Version: 4.0.23

[afonsocrg]

I had the same issue. After checking the createCors implementation I found the lines that may be causing this issue:

// Return new response with CORS headers.
return new Response(body, {
  status,
  headers: {
    ...Object.fromEntries(headers),
    ...rHeaders,
    ...allowOrigin,
    'content-type': headers.get('content-type'),
  },
})

To add multiple headers with the same name I had to use the headers.append method, so I believe that those lines should use this function instead. Later today I might create a PR to fix this, but I cannot do that atm

[kwhitley]

This has been addressed in the upcoming cors rewrite #226. :)

Thanks for the investigation and discussion - it was hugely instrumental to make sure these edge cases were covered!

That said, it's a bit of a good-news/bad-news situation.

The Good

• This case is covered, including test support
• We're supporting more CORS options (mirroring the options of express.js) and syntaxes
• We've managed to shed 120 bytes from the CORS function in the process (~600 --> ~480) :)

The Bad

• It's part of remedying a fundamental flaw in the existing implementation, which is a breaking change, so we started over
• This will be part of the v5.x release, that'll come with a couple powerful additions (supercharged routers) and a small housekeeping breaking change to save bytes by dropping compatibility support.

Stay tuned!

[kwhitley]

This has been fully addressed in the v5 release! Thanks again all!