Based on the discussion in#976

tldr; we add sessions to OPTIONS already, as long as the path matches the cookie settings, except for the rare but validOPTIONS * request

#976 (comment)

Actually this isn't a spec issue. The spec informs that this is a valid request, and Node lets it through because of that. But whether the request matches the path we've configured is up for debate. We're comparing the path option for cookies to the request's path.

The semantics of cookie path matching and wildcard requests don't map well to each other. Given a specific path like:cookieOptions.path = "/api/v1/" we are checking that we allow everything under it's subdirs such as/api/v1/foo || /api/v1/foo/bar/baz, while blocking/api/v2/foo. So I'd considercookieOptions.path = /api/v1/ to not match* because our cookie is set granularly.

But the default iscookieOptions.path = "/" which covers all subdirs on the domain. I'd consider that equivalent to* and would expect the options wildcard request to pass under the default.

I don't think anyone else handles this,fastify session would also not match the path for example.

So if a change was going to be taken, it should be to treat a wildcard as semantically the same as when the cookie path is set to all subdirs. Because apparently HTTP has more than one way to express "all subdirs" by way of the options wildcard request-target. TIL

(note: should anyone bother with sessions on OPTIONS? also up for debate! but the reality is rn we would dress all options requests in sessions with the default settings, except these wildcard ones)