Standardize access to cookie headers

[blittle]

As outlined at WHATWG/fetch there is often the need in a server environment to access cookie headers.

For example editing Cookie headers:

const h = new Headers;
h.append("Set-Cookie", "a=1; Expires=Wed, 21 Oct 2015 07:28:00 GMT");
h.append("Set-Cookie", "b=1; Expires=Wed, 21 Oct 2015 07:28:00 GMT");

h.get("Set-Cookie")
// a=1; Expires=Wed, 21 Oct 2015 07:28:00 GMT, b=1; Expires=Wed, 21 Oct 2015 07:28:00 GMT

Headers.prototype.getAll would solve this problem, but was removed from the browser specification. Should we standardize on adding it back? Or should we define a new method all together? Ideally we should align with node-fetch and undici as well.

[KhafraDev]

There's a proposal to add cookieStore options to the Request and Response constructors. That could solve cookie handling issues if it's automatically propagated with any set-cookie headers. Of course, fetch implementations could also add .getAll('set-cookie') (similar to what cf workers has) and let the dev create their own CookieStore if they need to parse the cookies.

=> CookieStore spec

[lucacasonato]

This is already being solved in the upstream fetch spec: https://github.com/whatwg/fetch/pull/1346.

[jimmywarting]

just popping in this little side note: https://github.com/whatwg/fetch/issues/1384 if a CookieStore could maybe perhaps serve as an alternative solution. of sending/reading cookies

[balazsorban44]

Note, there is a spec now for .getSetCookie(). See https://developer.mozilla.org/en-US/docs/Web/API/Headers/getSetCookie

[andreubotella]

Indeed, with the addition to getSetCookie to upstream fetch in whatwg/fetch#1346, and this fork allowing server-side runtimes to not filter cookie headers in #19, I think this issue can now be closed.