HttpOnly is ignored by the parse function

[mwanago]

When we call the parse function with a cookie that contains the HttpOnly clause, it gets ignored.

const cookie = require("cookie");

const parsedCookie = cookie.parse(
  "Authentication=token; HttpOnly;",
);

console.log(parsedCookie.Authentication); // Works as expected
console.log(parsedCookie.HttpOnly); // Prints undefined

What do you think , should it be true instead of undefined?

[wesleytodd]

I agree, and looks like maybe @UlisesGascon plans on addressing this? If not, I am sure a PR for this would be welcome!

[UlisesGascon]

I think there must be a bug, also there are no test cases for this (AFAIK). So the fix for this might be considered as a major, as is changing the current behavior of the library?

Based on the readme see:

httpOnly

Specifies the boolean value for the [HttpOnly Set-Cookie attribute][rfc-6265-5.2.6]. When truthy, the HttpOnly attribute is set, otherwise it is not. By default, the HttpOnly attribute is not set.

I assume that we expected true in this case as the value is truthy.

So all these cases should return true

"Authentication=token; HttpOnly;"
"Authentication=token; HttpOnly=;"
"Authentication=token; HttpOnly=1;"
"Authentication=token; HttpOnly=true;"

And these false

"Authentication=token; HttpOnly=0;"
"Authentication=token; HttpOnly=false;"

But in any scenario we should return undefined unless the world HttpOnly is not included.

"Authentication=token;",

Am I correct @wesleytodd?

Additional information can be found at RFC6265

[wesleytodd]

Yeah, I took a quick look (not a deep dive) and I think it is a bug and so doesn't really need to be a major. As for the expectations, I think that you are reading that right and so your examples are correct expectations. I am not sure they are good expectations, and that maybe things should become more strict in the future, but that is not really required to address now imo.

[alexanderwanyoike]

Ummm this seems like a major issue as https://github.com/vercel/next.js uses this package for NextCookie. @ijjk Please confirm. Seems that other options are being affected too such as Secure

[pi0]

From https://github.com/jshttp/cookie/issues/115#issuecomment-722841353, i am understanding that @dougwilson pointed out:

The Cookie header does not have httponly and secure flags like you are showing; that is the Set-Cookie header, which this module does not provide a parsing function for.

Maybe clearly separate parser for Set-Cookie would make better sense? (This is what we plan for cookie-es)

Don't get me wrong, I love the idea of supporting both, I'm, not explicitly against cookie package supporting both Cookie (current) and Set-Cookie (with boolean attributes like HttpOnly and Secure.

[lorenzo-dallamuta]

Should the new behavior which considers [cookieName]; to be the same as [cookieName]=true; only work with HttpOnly or also with any other cookie name?

[wesleytodd]

Ah! Yeah it is such a common issue brought up here and I totally forgot. @pi0 is right on. This module parses the Cookie header, not the Set-Cookie header. We can close this I think (feel free to re-open if you think I am wrong).