Multiple Set-Cookie headers folded into one header
In the documentation (https://developers.cloudflare.com/workers/runtime-apis/headers/), it says that "the Headers.append method will allow you to set multiple Set-Cookie response headers instead of appending the value onto the existing header."
However, the following code produces a single concatenated
Set-Cookie
header when sent to the client:
const headers = new Headers();
headers.append('Set-Cookie', 'cookie1=1;');
headers.append('Set-Cookie', 'cookie2=2;');
return new Response(null, headers);
getAll
works properly in the Workers environment, but entries
shows only a single Set-Cookie
header. On the client, only a single header, like so:
Set-Cookie: cookie1=1;, cookie2=2;
This behavior breaks from spec and the docs and prevents me from setting multiple cookies on a single request. Browsers do not properly interpret a single Set-Cookie
header.
Is this a bug? Or am I missing something? How can I have multiple Set-Cookie
headers on my response?8 Replies
return new Response(null, headers);that's not going to work since new Response second parameter wants a RequestInit, not headers This workers fine for me in a deployed worker though:
If you're testing in the Workers playground or dashboard quick edit it looks like it makes it visually append, but they don't in the actual response headers
Ah, my mistake, I have
{ headers }
in my code and it doesn't work
Even stranger behavior: it's working fine in Safari but not in Firefox or Chrome.on a deployed worker? Could you share the test endpoint?
iirc some web browsers do support multi-cookie sets in a single header but it's weird/not fully supported, might explain some of the behavior
I tried this in the playground and deployed that worker, it works fine. But I deployed my worker and the bug persists even after deployment. Going to expose a route that doesn't require auth to access for you to see
Aha, debugged!
Turns out this was an issue with
itty-router
's corsify
I'll try the latest and if that doesn't work I'll take it up with @Kevin W - Itty 😉I know we’re already chatting about this in itty.dev Discord, but we are talking about the corsify from v5 cors() not v4 createCors() right?
Yes, I bumped to 5.0.5 to see if that would fix it but it persists
See output here...
https://discord.com/channels/832353585802903572/1224742032610955364
We have a test setup at both:
https://tests.itty.dev/raw-cors (no itty, just creates a raw response and returns it)
https://tests.itty.dev/autorouter-cors (
AutoRouter
with cors()
)
...and both appear to work flawlessly (and identically) in Chrome.