Cookie with path other than root not sent to handlers

[ernestostifano]

Prerequisites

• I confirm my issue is not in the opened issues
• I confirm the Frequently Asked Questions didn't contain the answer to my issue

Environment check

• I'm using the latest msw version
• I'm using Node.js version 18 or higher

Browsers

Chromium (Chrome, Brave, etc.)

Reproduction repository

https://codesandbox.io/p/sandbox/cocky-torvalds-nsmhv6

Reproduction steps

Just visit the CodeSandbox and see how goodCookie is visible, but badCookie is not.

Current behavior

Cookies with paths other than / are not being sent.

If you set two cookies as follows:

      return HttpResponse.text("COOKIES SET", {
        headers: [
          [
            "Set-Cookie",
            "goodCookie=goodCookie; Path=/; SameSite=None; Secure; Max-Age=20;",
          ],
          [
            "Set-Cookie",
            "badCookie=badCookie; Path=/some/path; SameSite=None; Secure; Max-Age=20;",
          ],
        ],
      });

When making api calls to correctly matching paths, goodCookie is sent properly, but badCookie is not.

• Both cookies are correctly in the browser. It is an issue during requests.
• I can confirm that the issue is not present if using @mswjs/http-middleware.
• It works if you go to /some/path (https://nsmhv6.csb.app/some/path) in the CodeSandbox. Probably MSW is using the browser's URL and not the request URL to match cookies to send?

Expected behavior

I expect cookies to behave according to the specified path upon creation.

[kettanaito]

Hi, @ernestostifano. Thanks for reporting this!

I am frankly a bit lost in our existing cookie logic. It's been some years since it was originally written, and I'm trying to dig for the context behind every decision. I suspect that most of the things we have right now can be thrown away in v2.0.

Also, @chrisguttandin has referenced an issue in the cookie store package that may be helpful to me in uncovering the context:

#435

I've thrown together a new implementation for the cookie store, the one that will respect path and also domain: mswjs/cookies#34. But I need to understand the logic we have in place now before making any changes to MSW.

In summary, there are two surfaces dealing with cookies:

• Response cookies. Whenever you have Set-Cookie on a mocked response, MSW writes those cookies to document.cookie.
• Request cookie forwarding. When you make a request A that sets mocked cookies in the response, and then request B with a matching origin/path, MSW should include the relevant cookies in the request B.
• Response resolver cookies. This can be similar to no.2 but I suspect we gather these cookies just to present to the developer. Ideally, it should be the same as no.2.

[kettanaito]

I've also discovered that JSDOM doesn't write cookies to document.cookie if their path doesn't match the mocked location address. This is incorrect and is not how the browser behaves, after which all JSDOM behaviors must be modeled.

In the browser, you can write any cookies to document.cookie. Then, only when making a request, given the permissive credentials option, the browser will see which cookies from document.cookie are relevant. You can provide this behavior by yourself by writing a cookie with a non-matching path and opening Application > Cookies in the devtools. You will see all document cookies.

In JSDOM, nothing will be written.

// jsdom
// Given location is the default location of
// http:https://localhost/
document.cookie = 'a=b; Path=/foo'

This makes automated testing on our end a bit problematic. We may consider switching the test suite of the cookie store to run in the actual browser. That library is still designed for Node.js as well to act as a singleton and a replacement layer for cookies in Node.js (where no document.cookie exists).

[kettanaito]

Opened a branch with a WIP fix/wip-cookie-path-match.