Warn or fail for non-zero expire dates in the distant past

[dfabulich]

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:

Expiration Dates

This proposal side-steps date parsing issues by only accepting timestamps (milliseconds since UNIX epoch), like the lastModified attribute in the File API.

JavaScript Date objects will be automatically converted to timestamps thanks to implicit conversions.

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:

try {
  await cookieStore.set({
    name: 'session_id',
    value: 'this data will be LOST',
    expires: 365 * 24 * 60 * 60 * 1000 });
} catch (e) {
  console.error(`Failed to set cookie: ${e}`);
}

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 or expires: 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.)

[annevk]

I actually think we should offer max-age as a convenience for developers.

[dfabulich]

That’s #57, closed. Maybe you can help them see reason about this!

[annevk]

Happy to try. w3ctag/design-principles#425 has some further discussion why this is a good idea.

[inexorabletash]

@ayuishii wasn't there a recent conversation about this between you and...?