Adding or deleting multiple cookies with the same name only modifies the last one

[Avaq]

Describe the bug

When I try to set or delete multiple cookies that share the same name (but exist on different paths) using the event.cookies API, then only the last call is retained.

I have found no work-around within SvelteKit, because the event.setHeaders API states:

You cannot add a set-cookie header with setHeaders — use the cookies API instead.

Reproduction

A Server Load function like the following highlights the issue. When it runs, the resulting set-cookie headers only include the key cookie once, but it should be included twice.

I was not able to reproduce this on Stackblitz because they seem to be difficult about setting cookies. Here's how to reproduce it locally:

Code

routes/test/+page.server.js:

export const load = (event) => {
  event.cookies.set('key', 'value', { path: `/foo/` });
  event.cookies.set('key', 'value', { path: `/bar/` });
}

routes/test/+page.svelte:

Hello world

Reproduction

• Serve your app on localhost
• Open the network inspector in your browser
• Load the page at localhost/test
• Observe the response headers

Expected result

set-cookie: key=value; Path=/foo/; HttpOnly; SameSite=Lax
set-cookie: key=value; Path=/bar/; HttpOnly; SameSite=Lax

Actual result

set-cookie: key=value; Path=/bar/; HttpOnly; SameSite=Lax

Logs

System Info

n/a

Severity

serious, but I can work around it

Additional Information

It seems that SvelteKit treats cookies as "unique by name", whereas it should be treating cookies as "unique by (at least) path and name":

kit/packages/kit/src/runtime/server/cookie.js

Line 216 in 217fc24

new_cookies[name] = { name, value, options: { ...options, path } };

It might be that other fields should be considered as well for creating a unique cookie identifier, such as the domain property.

[fraser-0]

I have the same issue. I can't clear cookies (using SvelteKit methods) with the same name but different domains, which breaks my ability to change the domain scope of a cookie. If I have a cookie foo with value bar that is set to domain dev.website.com for 30 days and then I want to update the cookie to have the value baz and change the domain scope to .website.com you can't clear the cookie foo that is scoped to dev.website.com in the same request because SvelteKit treats cookies unique by name. This results in the browser rightfully having two cookies with these values but no way to clear so when you read that cookie in sveltekit you don't get the latest one that is scoped to .website.com but you get the original one scoped to dev.website.com which has the wrong value.

SvelteKit should adopt scoping based on domain and path as outlined in the Mozilla documentation

[yuki0418]

@Avaq
I create a reproduction but I can see both set-cookies in the response header in @sveltejs/kit@2.25.1.
Do you still have the issue in your environment?

[Avaq]

@yuki0418 it looks like your reproduction uses two differently named cookies. The problem only occurs if both cookies have the same name

[yuki0418]

@Avaq
whoops!!
Sorry I just changed a key name.
Yes you right, now I see only one set-cookie.

[yuki0418]

@dummdidumm

Apologize for mentioning if it is impolite.
I'm new and need bit advices.

I think this line of code using a cookie name as key of array causes this issue. And I think using Set instead is a solution for this.

kit/packages/kit/src/runtime/server/cookie.js

Line 216 in fda0165

new_cookies[name] = { name, value, options: { ...options, path } };

Do you have an any other thoughts?

[Avaq]

@yuki0418 I've already included a link to that line in my original bug report

A fix would be just use a string that includes the domain and path as well, eg:

cookies[`${domain}${path}?${name}`] = cookie

So the identifiers become example.com/foo?key and example.com/bar?key, making them unique.

[yuki0418]

@Avaq
Thank you!

This is more complicated than I thought.

The get function in cookies receives only the key name and CookieParseOptions to find a cookie.

kit/packages/kit/src/runtime/server/cookie.js

Lines 57 to 62 in fda0165

	/**
	* @param {string} name
	* @param {import('cookie').CookieParseOptions} [opts]
	*/
	get(name, opts) {
	const c = new_cookies[name];

If we use cookies[${domain}${path}?${name}] = cookie, a user would need to call the get() function with the key name, domain, and path together, like:

// +page.server.ts
cookies.set('key', 'value', { path: `/foo/` });
const cookie = cookies.get('/foo/?key');

Alternatively, we could modify the get function to accept get(name, opts, cookieOpts: { domain, path }), but that would be a breaking change.

I'm reading the code more carefully to think of a better solution.

[Avaq]

I think the former (changing the cookie identifier format outwardly) is a bigger breaking change than adding a new parameter to allow users to supply a path and/or domain.

[yuki0418]

You are right.

I will try modify parameter like

/** 
 * @param {string} name 
 * @param {import('cookie').CookieParseOptions | {domain: string?, path: string?}} [opts] 
 */ 
 get(name, opts) {
    // find a cookie for name, domain, and path if option contains domain or path

[Rich-Harris]

Opened #14131 which I think fixes this; would welcome input. (Background: #14056 (comment))

One thing this doesn't (and can't) fix is this case:

• your browser has a cookie, foo=1; Path=/x/y/z
• you go to /x/y/z
• you do cookies.set('foo', 2, { path: '/' })
• later, you do cookies.get('foo')

This should return 1, because the earlier cookie is more specific, but SvelteKit doesn't have access to the path, just the value. So it assumes that the value that was just set — 2 — is the correct one.

The solution to this is 'for the love of god, don't use the same cookie name on different paths'