Open dfabulich opened 4 years ago
I actually think we should offer max-age as a convenience for developers.
That’s #57, closed. Maybe you can help them see reason about this!
Happy to try. https://github.com/w3ctag/design-principles/issues/425 has some further discussion why this is a good idea.
@ayuishii wasn't there a recent conversation about this between you and...?
Issue #57 was closed. I object, but I have no voice in this. 🤷♂️
In the course of closing it out, a note was added to the explainer:
But this cheerful note needs to be a warning to developers. It gives no hint at all about why only offering an
expires
timestamp is prone to data loss in the case of developer error.Consider this example:
Superficially, it looks like this cookie will last for a year, but in fact,
31536000000
is midnight of 1971 UTC. It will silently delete the cookie data the instant you set it, resulting in data loss.I suggest that the API should warn (or maybe even throw) if the user provides an expires date that's greater than 0 but less than a very large number, like 1514764800000 (1/1/2018 UTC) or something.
In 2020, there is no sane reason to set a cookie to expire in 1971. Anyone who writes
expires: 30
orexpires: 1000
is incurring a data-loss bug with this API; the API should help developers by at least warning them when they inevitably make this mistake.(Maybe you think "nobody would make that mistake," but the two most popular client-side JS cookie libraries https://github.com/js-cookie/js-cookie and https://github.com/ScottHamper/Cookies both accept "flexible"
expires
options, where if you pass them as numbers, they're interpreted relative to now; you have to pass JS Date objects if you want to use an absolute timestamp. If you try that with the Cookie Store API, you're screwed.)