Allow setting a maxAge

[aamuley]

Add maxAge as a CookieInitOption used in cookieStore.set(options). Related to #57 #162

I was inclined to use a long long and allow the rfc to handle limiting the cookie ttl to 400 days if there is a restriction imposed there. A long might overflow a bit earlier than expected ~10 years and expire the cookie immediately but im not sure if protecting against that is actually needed.

• At least two implementers are interested (and none opposed):
  • Chrome
  • …
• Tests are written and can be reviewed and commented upon at:
  • tbd, getting reviewed on https://chromium-review.googlesource.com/c/chromium/src/+/7158367
• Implementation bugs are filed:
  • Chromium: …
  • Gecko: …
  • WebKit: …
• MDN issue is filed: …
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

Preview | Diff

[annevk]

For other fields we have some validation. Do we want to throw if both expires and maxAge are passed?

[aamuley]

hmm i was planning to let that decision fall to the rfc and just prefer the maxAge if both are specified since that might be more expected behavior for devs, wdyt @DCtheTall?

[annevk]

Once we start targeting the layered-cookies I-D instead of the current RFC, I'm pretty sure we'll need to resolve the duplication locally anyway as we're not going to serialize what we have and feed it into the parser, but instead we'll create a cookie instance here and use that.

[aamuley]

Oh I didnt realize that, happy to check which is specified and throw an error in that case. Would you rather we construct a unified expiry time (between max-age and expires) in this algorithm right now, or leave that for when the RFC is being updated?

[annevk]

I think we should leave that until we update this specification to target the layered-cookies I-D.

@bakulf thoughts on all this?

[DCtheTall]

LGTM, just one suggestion