impl CookieStore?

[jimmywarting]

What is the problem this feature will solve?

Cookie parsing and serializing is tuff. Most often you need a cookie plugin for whatever reason and dose are downloaded milion of times / week on npm

Adding a memory based CookieStore that can be constructed using new CookieStore() in some form would be beneficial. I'm just imagining http, https, http2 and fetch to have support for passing in own custom CookieStore parameter somewhere for it to be used somehow

[benjamingr]

@jimmywarting the primary issue with something like this is that Node programs often serve multiple users (e.g. http servers) whereas web APIs are built for single-tenancy.

The web API doesn't currently allow new CookieStore() to set up an empty store and Node can't expose an equivalent of document.cookie (nor do any of the current APIs even support cookies for the abovementioned reason).

There definitely is the case for http clients in Node finding this useful though given the web API doesn't expose CookieStore the way it does EventTarget not sure if that's even reasonably explorable?

[jimmywarting]

To be honest i don't even know if it would fit in nodejs also as you mention "it serve multiple users" you would kind of have to construct a new CookieStore for each and every user then. but i created this issue just to discuss/explore if it is reasonably

But for things that don't work with multiple users, like a Slack, Twitter or Github client you might just only need one cookie store to communicate with one api.

it's true that CookieStore ins't constructible, but would mean that we would have to be restricted to the same rule as the browser.

given the web API doesn't expose CookieStore

what do you mean? CookieStore is exposed globally (but just in secure contexts)

Node can't expose an equivalent of document.cookie

CookieStore dosen't have to be based on document.cookie. in some issue i read that they wish to deprecate the old document.cookie in like 5y time or something (wishful thinking). don't belive CookieStore is even based on document.cookie at all, it's just a rewrite.

[targos]

To be honest i don't even know if it would fit in nodejs also as you mention "it serve multiple users" you would kind of have to construct a new CookieStore for each and every user then. but i created this issue just to discuss/explore if it is reasonably

I personally think it makes sense. Most of my apps do not make HTTP requests on behalf of the user, even in the context of responding to them. Usually they talk to internal web services and use the same credentials regardless of the user that triggered the request.

[jimmywarting]

it would have been nice if you didn't need a cookie jar plugin or something like fetch-cookie to intercept all redirects and having to reimplement all redirect logic yourself and changing redirect to manual. I agree with everything in whatwg/fetch#1384 (comment) so i do think a CookieStore have some huge value also. we would just have to make some node changes to make a CookieStore fit in a nodejs context if that is necessary. like making it possible to read each and every cookie that also has httpOnly flag

maybe CookieStore dose not have to be constructable in the same way... maybe we could create some util that give us some new instances of a CookieStore const cookieStore = require('node:cookie-store').from(something)

[benjamingr]

what do you mean? CookieStore is exposed globally (but just in secure contexts)

Thanks, I tested in example.com -_-

I think experimentation is worth exploring then and support in undici

[github-actions]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[benjamingr]

Please keep open

[B1773rm4n]

What is the status?

[github-actions]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[carlosfdiazsanchez]

Keep open