What is the reason behind converting the `cookie.maxAge` prop to an `Expires` value in the actual cookie?

[bttger]

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the issue has not already been raised

Issue

getCookieOpts() always converts the maxAge property to the expires property by creating a new Date and adding the maxAge to the current server's time. The returned object omits the maxAge property then. I believe this creates issues if the client's time is out of sync and goes against the expected behavior.

What is the rationale behind this design choice? To be honest, I hope the answer is not just "because express does it the same way" 😅

[bttger]

Oh, and I again stumbled upon this because I had the following issue: attestate/better-sqlite3-session-store#13

[climba03003]

I believe this creates issues if the client's time is out of sync and goes against the expected behavior.

If the client time is out of sync. Max-Age and Expires has no different, both will goes against the expected behavior.

What is the rationale behind this design choice?

I didn't create the plugin in beginning. But for me, I would prefer Expires more than Max-Age.
The main reason is that it is more easy to see when it should be expired. For Max-Age, we need to calculate a bit before knowing the expire date-time.

[bttger]

If the client time is out of sync. Max-Age and Expires has no different, both will goes against the expected behavior.

No, the Max-Age is a relative time while Expires is absolute. For the Max-Age it doesn't matter if the client's time is out of sync and I believe that this is also why it always takes precedence over the Expires value (according to RFC 6265)

For Max-Age, we need to calculate a bit before knowing the expire date-time.

I am not sure if I understand what you'd need to calculate. When setting/touching the session, you would only instantiate a new Date like the current getCookieOpts() does it already to be able to set it in the DB and check if a session is still valid later on. When setting/touching the actual cookie you would only pass the cookie.maxAge value without any calculation (except for maybe dividing by 1000 because for whatever reason express-session and fastify-session use milliseconds). What is there that you would need to calculate?

[climba03003]

No, the Max-Age is a relative time

It is relative to the creation time, when the time of computer is out-of-sync. It will still calculated from the out-of-sync time.
How can it determine the time elapsed without referring to the computer time?

What is there that you would need to calculate?

How can you directly know when it should be expired without calculation?
When you inside the code, it is setting max-age and I will do so. But when debugging, if there is only Max-Age attributes in the cookie, I need to read it and calculate when to expired by my own before knowing exact date-time.

[bttger]

It is relative to the creation time, when the time of computer is out-of-sync. It will still calculated from the out-of-sync time. How can it determine the time elapsed without referring to the computer time?

Yes, right. The elapsed time can only be reliably calculated assuming the client stays out of sync. But that is not what I want to discuss about. What I am asking is, why the cookie.maxAge is not applied to the cookie but converted to an Expires value instead. This makes no sense to me and definitely goes against the developers expactation.

[climba03003]

I believe the RFC note in below is a valid reason.

  NOTE: Some existing user agents do not support the Max-Age attribute.  User agents that do not support the Max-Age attribute ignore the attribute.

Discussion in Express also mention about it.

[climba03003]

Please be aware that this package is made to be compatible to express-session. The decision on implementation is most likely affected by or inherit from express-session.

@fastify/cookie do allow you to set Max-Age if you wish.

Is that answer your question?

[Uzlopak]

Well for me expires makes much more sense than maxAge. E.g. you can easily debug and see when it will expire, while with maxAge you somehow have to know when the cookie was created and calculate it. Also expires is set to the same value as in the session store.

I dont see any benefit to use maxAge

[bttger]

I believe the RFC note in below is a valid reason.

  NOTE: Some existing user agents do not support the Max-Age attribute.  User agents that do not support the Max-Age attribute ignore the attribute.

Discussion in Express also mention about it.

The RFC note is from 2011 and, according to the link shared in the express discussion, Internet Explorer was the only browser not supporting it until version 8 which was in 2009. In all previous projects I have used Max-Age and never had issues.

[Uzlopak]

But if you think, that maxAge is much more awesome, you can provide a PR which adds the desired functionality.

[bttger]

Please be aware that this package is made to be compatible to express-session. The decision on implementation is most likely affected by or inherit from express-session.

@fastify/cookie do allow you to set Max-Age if you wish.

Is that answer your question?

I'm happy for having fastify-session and not having to implement it myself, so I'll stick with it. Thanks for your quick answers.

[climba03003]

But if you think, that maxAge is much more awesome, you can provide a PR which adds the desired functionality.

Unless express-session changed, I would be keep it for now.
This package is used to be similar or inherit the behavior of express-session.

[bttger]

But if you think, that maxAge is much more awesome, you can provide a PR which adds the desired functionality.

Thank you, but I'll try to address the issue I have with the maintainer of the session store. I have already implemented a fix but we were discussing whether it makes sense to merge the PR.

[Uzlopak]

The sessionstore does not decide if maxAge or Expires is sent

[bttger]

The sessionstore does not decide if maxAge or Expires is sent

Yes but it reads the session.expires and session.maxAge values to set the correct expiration time. And in case of the session store I am using, it only reads the maxAge value.