Awesome thanks! I believe I did cover the maxAge + expires case in the WPTs already ( https://github.com/web-platform-tests/wpt/blob/master/cookiestore/cookieStore_set_maxAge.https.any.js#L46 )?
On Mon, Jan 12, 2026 at 10:23 AM Mike Taylor <[email protected]> wrote: > LGTM3 - but can you also add a test for the "setting a cookie w/ maxAge + > expires results in a TypeError" scenario? > > On 1/9/26 6:29 p.m., 'Anusha Muley' via blink-dev wrote: > > Hey, > > So for Mike's feedback: > >> I don't see any mention of the concept of "cookie-age-limit" (400 days) >> that 6265bis defines - how does that work for CookieStore? >> https://www.ietf.org/archive/id/draft-ietf-httpbis-rfc6265bis-22.html#section-5.5 > > > The Cookie Store API sends the maxAge value to 6265bis to be stored in > https://cookiestore.spec.whatwg.org/#set-cookie-algorithm, the 400 day > limit is enforced at that level instead of in this specification. The > cookie would be set with a max age of 400 days if the value exceeds that > amount. > > Thanks for pointing that out - that wasn't obvious to me. > > > Step 13.1 of https://cookiestore.spec.whatwg.org/#set-cookie-algorithm >> <https://www.ietf.org/archive/id/draft-ietf-httpbis-rfc6265bis-22.html#section-5.5> >> returns >> failure when a cookie has both expires and max-age, but >> https://www.ietf.org/archive/id/draft-ietf-httpbis-rfc6265bis-22.html#section-5.7 >> requires >> that max-age wins. Is there any reason for the difference for Cookie Store? > > > The logic was suggested by Anne here > <https://github.com/whatwg/cookiestore/pull/292#pullrequestreview-3479097170>. > The expectation is that this behavior will soon be enforced in 6265bis, but > since this is a new API we would prefer to start throwing errors now, > instead of having to specify this behavior later and break callers? Lmk if > that is unreasonable. > > I'm a bit skeptical you could actually make this change to HTTP cookies, > but assuming nobody is passing in maxAge and expires today via CookieStore > (in theory possible, but I couldn't find anything), then starting to throw > now as devs start to use it makes sense. > > > Can we add a test for max-age=0 value? This has been recently allowed >> explicitly in the grammar defined in 6265bis (and is supported by all >> browsers): > > > Sounds good, https://github.com/web-platform-tests/wpt/pull/57119 > > > And Jeffrey's: > >> Have you considered Temporal integration, since Temporal is shipping in >> M144? I suspect the right behavior is to overload between a `number` and a >> `Temporal.Duration`. > > > I am not sure how needed that is for developers, it seems pretty simple to > set maxAge to be Temporal.Duration.seconds > <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Temporal/Duration/seconds> > for > that case. Welcome to hear other opinions though, and there is an ongoing > discussion you might be referencing about temporal timestamps generally > that might need IDL-side changes and seems out of scope of this feature on > https://github.com/whatwg/cookiestore/issues/243? > > On Thu, Jan 8, 2026 at 2:30 PM Jeffrey Yasskin <[email protected]> > wrote: > >> Have you considered Temporal integration, since Temporal is shipping in >> M144? I suspect the right behavior is to overload between a `number` and a >> `Temporal.Duration`. >> >> On Thu, Jan 8, 2026 at 8:47 AM 'Anusha Muley' via blink-dev < >> [email protected]> wrote: >> >>> >>> Contact emails >>> >>> [email protected] >>> >>> Explainer >>> >>> No information provided >>> >>> Specification >>> >>> https://github.com/whatwg/cookiestore/pull/292 >>> >>> Summary >>> >>> Allows callers to specify a `maxAge` when setting a cookie with the >>> Cookie Store API. Cookie expiry time is already configurable using the >>> `expires` attribute, but `maxAge` provides a more idiomatic option and >>> aligns the Cookie Store API with the options provided by `document.cookie` >>> and the `Set-Cookie` HTTP Header. >>> >>> Blink component >>> >>> Blink>Storage>CookiesAPI >>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EStorage%3ECookiesAPI%22> >>> >>> Web Feature ID >>> >>> cookie-store <https://webstatus.dev/features/cookie-store> >>> >>> Motivation >>> >>> Currently, developers can use the `expires` attribute when setting a >>> cookie with the Cookie Store API to set an absolute timestamp for expiry. >>> This can be unintuitive and is impacted by client-side clock skew. >>> RFC6265bis >>> <https://datatracker.ietf.org/doc/draft-ietf-httpbis-rfc6265bis/> and >>> the document.cookie API provide a `Max-Age` attribute, which allows for >>> relative cookie lifetimes and ergonomic deletion. We should provide a >>> `maxAge` option in the Cookie Store API to support relative expiry and >>> align with these APIs. >>> >>> Initial public proposal >>> >>> https://github.com/whatwg/cookiestore/issues/57 >>> >>> TAG review >>> >>> Not requested, this is a relatively small feature that has no impact on >>> behavior or new information exposed through the API. >>> >>> TAG review status >>> >>> Not applicable >>> >>> Risks >>> >>> >>> Interoperability and Compatibility >>> >>> Additive feature with no impact to existing cookies/behavior. Does not >>> expose additional information or functionality-- setting a cookie's >>> absolute expiry with the `expires` value is already supported in the API. >>> >>> Gecko: Positive ( >>> https://github.com/mozilla/standards-positions/issues/1334) >>> >>> WebKit: No Signal ( >>> https://github.com/WebKit/standards-positions/issues/597) >>> >>> We are actively developing this feature in collaboration with WebKit >>> https://github.com/whatwg/cookiestore/pull/292#pullrequestreview-3538599229 >>> >>> Web developers: Positive ( >>> https://github.com/whatwg/cookiestore/issues/57) Could be easier for >>> developers to work with now-relative values, aligns the Cookie Store API >>> with the features provided by document.cookie and RFC6265bis >>> >>> Other signals: >>> >>> WebView application risks >>> >>> Does this intent deprecate or change behavior of existing APIs, such >>> that it has potentially high risk for Android WebView-based applications? >>> >>> No >>> >>> >>> Debuggability >>> >>> Cookies (and their properties such as expiry time) are debuggable >>> through the Application > Cookies tab on DevTools >>> >>> Will this feature be supported on all six Blink platforms (Windows, Mac, >>> Linux, ChromeOS, Android, and Android WebView)? >>> >>> Yes >>> >>> Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ? >>> >>> Yes >>> >>> >>> https://wpt.fyi/results/cookiestore/cookieStore_set_maxAge.https.any.html?label=master&label=experimental&aligned >>> >>> >>> https://wpt.fyi/results/cookiestore/cookieStore_set_maxAge.https.any.serviceworker.html?label=master&label=experimental&aligned >>> >>> >>> Flag name on about://flags >>> >>> No information provided >>> >>> Finch feature name >>> >>> CookieStoreAPIMaxAge >>> >>> Rollout plan >>> >>> Will ship enabled for all users >>> >>> Requires code in //chrome? >>> >>> False >>> >>> Tracking bug >>> >>> https://issues.chromium.org/430926231 >>> >>> Estimated milestones >>> >>> Shipping on desktop >>> >>> 145 >>> >>> Anticipated spec changes >>> >>> Open questions about a feature may be a source of future web compat or >>> interop issues. Please list open issues (e.g. links to known github issues >>> in the project for the feature specification) whose resolution may >>> introduce web compat/interop risk (e.g., changing to naming or structure of >>> the API in a non-backward-compatible way). >>> >>> None >>> >>> Link to entry on the Chrome Platform Status >>> >>> https://chromestatus.com/feature/5190778418757632 >>> >>> This intent message was generated by Chrome Platform Status >>> <https://chromestatus.com/>. -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68847eee-f32e-4ef8-85f1-1413a18a2bcen%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68847eee-f32e-4ef8-85f1-1413a18a2bcen%40chromium.org?utm_medium=email&utm_source=footer> >>> . >>> >> -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOJwDD54Swah7GeuvZ5R01JfphQ9E4WVemXZW9y8QvDwf%3D_tyQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOJwDD54Swah7GeuvZ5R01JfphQ9E4WVemXZW9y8QvDwf%3D_tyQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOJwDD7qJ3vERJdvgfTg4HD1ZuChCYPR8YGcj%2BfMkiWTY3b7Vw%40mail.gmail.com.
