cookie.parse ignores HttpOnly; Secure;

[gerhardcit]

It seems that the parses wants key=value pairs and ignores the HttpOnly; Secure; settings?

import cookie from 'cookie';
const cookieStr = "MY_COOKIE=somevalue; Path=/; Expires=Tue, 29 Oct 2024 06:06:46 GMT; HttpOnly; Secure; SameSite=None";
const parsedCookie = cookie.parse(cookieStr, { decode: String });
console.log("parsedCookie", parsedCookie);

Result: (missing the HttpOnly and Secure settings?

parsedCookie C <[Object: null prototype] {}> {
  MY_COOKIE: 'somevalue',
  Path: '/',
  Expires: 'Tue, 29 Oct 2024 06:06:46 GMT',
  SameSite: 'None'
}

Expected result:

parsedCookie C <[Object: null prototype] {}> {
  MY_COOKIE: 'somevalue',
  Path: '/',
  Expires: 'Tue, 29 Oct 2024 06:06:46 GMT',
  HttpOnly: 'true',
  Secure: 'true',
  SameSite: 'None'
}

if the cookie value is explicit: HttpOnly=true; Secure=true

const cookieStr = "MY_COOKIE=somevalue; Path=/; Expires=Tue, 29 Oct 2024 06:06:46 GMT; HttpOnly=true; Secure=true;

then is parses correctly.

I tried 0.7.2 and 1.0.1. Am I missing something?

[gerhardcit]

#164 seems to discuss this. Does not seem that there is a consensus about what to expect?

[blakeembrey]

There is a consensus, this package doesn’t parse the Set-Cookie header, which is what you’re trying to do. It says this in the README too, parses a Cookie header.

This could be added as a feature, but it’s unsupported today.

[gerhardcit]

@blakeembrey , thx.. duh!, you are very correct.
my source was this:

const setCookieHeaders = res.headers.getSetCookie();
for (const setCookieHeader of setCookieHeaders) {
....

We use it often in workers and sveltekit projects to pass a login method to my own upstream IDP and need to pass cookies (full or partly) on to the consumer, which has another hostname.

[blakeembrey]

@gerhardcit Would it be helpful if this library did support parsing the set-cookie header? I'm happy to consider it as a new feature in the near future.

[gerhardcit]

@blakeembrey , considering the amount of times that I intercept cookies from my own upstream servers in apps like sveltekit routes, (typically on cloudflare like serverless), i think it would be very useful.

1. browser calls sveltekit route (www.myapp.com)
2. sveltekit has to make a call to the upstream api (api.theapi.com). (need sending the cookies with, since the url changed
3. it get's cookies back from api.theapi.com (with the set-cookie header)
4. I need to: partly process, inspect, possibly modify and, send that on to the client on www.myapp.com.

Most of that is manual work since cookies are not passed through when urls changes, but often it needs to easily pass on (both are my apps after all, api.theapi.com serves various other myapps2... which are again sveltekit type apps where the api needs to go upstream.

Sveltekit documents this here: https://svelte.dev/docs/kit/@sveltejs-kit#Cookies
But when many urls and localhost http development are involved, I often find my self handle cookies more granular myself (as it might change name in the process)

Hopes this make sense and hopefully I'm not trying to reinvent some wheel which I have not seen of fully understand yet.

PS. in some cased I convert upstream cookies to some kind of encrypted response, since hybrid apps (ie Ionic wrapped with capacitor) and cookies is not great to work with, (even though there is a plugin for it) in which case I convert the incoming set-cookie from the upstream api to a encrypted jwt header and send that to the app client for later use.

So it would be very handy in my view.

[pimterry]

Just as another datapoint, I'd find this useful too @blakeembrey, definitely helpful to have support for both. I'm currently using cookie + set-cookie-parser to parse both, but they awkwardly behave in various slightly different ways.

[benmccann]

I would very much find it helpful if this library supported parsing the set-cookie header. Right now we have to depend on both cookie and set-cookie-parser, but I would love to reduce the number of dependencies that we have. Combining both pieces of functionality is also one of the key selling points of the cookie-es library.

[wesleytodd]

This is likely the most common feature request and misconception of this package. While I generally dislike having packages take on more scope (like after adding this, folks using this in the browser would need treeshaking to avoid loading additional code they may not need, for example) I think it would be justified in this case. If nothing else it would prevent this issue from being opened over and over again like it is.

[benmccann]

after adding this, folks using this in the browser would need treeshaking to avoid loading additional code they may not need

You could avoid that by making the new functionality available through a subpath export in package.json rather than through the default export