fix: parse "Set-Cookie" response header with commas correctly

[ushiboy]

• Closes Set-Cookie responses containing commas are not handled correctly #2074

Fixed to handle Set-Cookies containing commas.
If TypeScript is 5.2 or higher, getSetCookie in Headers can be used, but this has been fixed as a temporary measure at this time.

see also:

• https://developer.mozilla.org/en-US/docs/Web/API/Headers/getSetCookie
• Headers.prototype.getSetCookie microsoft/TypeScript#55270

[mattcosta7]

Since we build with 5.2+, and consumers shouldn't be getting typed output for this, can we just use headers.getSetCookie() or does that actually cause a consumer failure downstream?

consumer typescript shouldn't need to know I think, but we shouldbe able to still use it as long as getSetCookie is defined on the Headers prototype in the target environments

[mattcosta7]

{
  H: Object [Headers] {
    append: [Function: append],
    delete: [Function: delete],
    get: [Function: get],
    has: [Function: has],
    set: [Function: set],
    keys: [Function: keys],
    values: [Function: values],
    entries: [Function: entries],
    forEach: [Function: forEach]
  }
}

looks like our jsdom version doesn't have getSetCookie implemented, but typescript is fine with it

[mattcosta7]

What we implemented in Headers-polyfill was this https://github.com/mswjs/headers-polyfill/blob/67f31364053574f5b1b805aa0eb3cbd5cd49d915/src/Headers.ts#L182-L194

I think headers-polyfill is a dependency of msw still, and we could do something like HeadersPolyfill.prototype.getSetCookie.call(init.headers) as the lightest fix that avoids consumer issues

I think we could easily just ship it raw to users as init.headers.getSetCookie() but we're likely to run into many cases of tests failing due to the lack of definition in jsdom, which would require consumers to polyfill Headers in their tests, which adds a step, at the cost of potentially a few bytes.

The other option is that we suggest headers-polyfill be used for environments that don't have the correct headers implementations in place (jsdom, it's always you).

@kettanaito any preferences? I generally prefer just using getSetCookie directly, but also expect a lot of "this broke" commentary when/if we ship that

[ushiboy]

It seems that the latest version of jsdom Headers does not yet implement getSetCookie.
https://github.com/jsdom/jsdom/blob/24.0.0/lib/jsdom/living/fetch/Headers-impl.js

I too think it is better to use headers-polyfill to deal with this temporarily.
But it seems that HeadersPolyfill.prototype.getSetCookie.call(init.headers) would cause eslint to error.

msw/src/core/utils/HttpResponse/decorators.ts
  0:0  error  Parsing error: DeprecationError: 'originalKeywordKind' has been deprecated since v5.0.0 and can no longer be used. Use 'identifierToKeywordKind(identifier)' instead

✖ 1 problem (1 error, 0 warnings)

[mattcosta7]

weird, that looks like @typescript-eslint/parser is probably failing somewhere and maybe a version update fixes it, i'll try landing an update

[mattcosta7]

#2084

I think updating the ts-eslint dependencies like in that PR should fix this error, which isn't related to the dependency at all, but the linter breaking

[ushiboy]

Thanks, @mattcosta7
I have changed to use headers-polyfill.

[kettanaito]

We shouldn't tailor to technologies that violate standard support. We should rely on .getSetCookie() because it's a supported method. If the underlying environment doesn't support it, it's the underlying environment that should be fixing it (i.e. including any necessary polyfills). We mustn't rely on headers-polyfill anymore. It's used only for its utilities around transforming headers.

The only concern is what @mattcosta7 raised about the TypeScript supporting this method. It doesn't exist on earlier versions of TS:

• 4.7
• 4.8
• 4.9
• 5.0
• 5.1

And seems to only land in 5.2.

The Headers.prototype.getSetCookie can also be used only since Node.js 19 (which translates to v20 for stable releases) while MSW supports v18.

With this in mind, we cannot ship .getSetCookie() method as a part of MSW—it will break for a lot of people because it won't exist type-wise and runtime-wise.

We need to implement the logic/fix ourselves until TS 5.2 and Node.js v20 become the minimal supported versions, which is years in the future.

[kettanaito]

TL;DR

What you're doing is fine. Just the reasoning should be mentioned more prominently above this line.

Can you please include a comment above this HeadersPolyfill usage briefly describing why we rely on a polyfill here? Thanks!

[mattcosta7]

FWIW - typescript not supporting this in 4.7-5.1 shouldn't matter for consumers using those versions, because this call is encapsulated from their tooling (it's internal and generally node_modules aren't typechecked except at their .d.ts level which shouldn't contain any information about this call to getSetCookie

But with neither node18, jest not vitest able to support this correctly, we'd basically break everyone's tests the second we shipped it which would be unideal.

I'm very much onboard that jsdom needs to support this - although maybe one day people will test browser code in a browser....one day

We could also inline logic from the headerpolyfill here instead of using that directly, as another option to get away from the polyfill - it's just implemented there already

[kettanaito]

FWIW - typescript not supporting this in 4.7-5.1 shouldn't matter for consumers using those versions, because this call is encapsulated from their tooling

This is only true if they have skipLibCheck: true, which is not the default and many people still have it disabled, which will cause compilation problems. Granted, easy to fix but creates an unnecessary stress for consumers.

I'm very much onboard that jsdom needs to support this - although maybe one day people will test browser code in a browser....one day

Fingers crossed!

We could also inline logic from the headerpolyfill here instead of using that directly, as another option to get away from the polyfill - it's just implemented there already

See no reason to duplicate code. We depend on headers-polyfill anyway right now, its implementation is tested, we should use it.

[kettanaito]

This change is fantastic! Please, just add the comment above the HeadersPolyfill usage that explains we are using it due to the TS/runtime compatibility, not due to JSDOM.

[ushiboy]

@kettanaito
I have added a comment granting an explanation. Please check again.

[kettanaito]

Fantastic work. Thank you so much, @ushiboy @mattcosta7! Let's get this fixed.

[kettanaito]

Welcome to the contributors, @ushiboy! 👏

[kettanaito]

Released: v2.2.4 🎉

This has been released in v2.2.4!

• 📄 Release notes
• 📦 npm package

Make sure to always update to the latest version (npm i msw@latest) to get the newest features and bug fixes.

---

Predictable release automation by @ossjs/release.