Standardize maximum Expires/Max-Age

[arichiv]

The current spec is ambiguous on (1) what the maximum Expires/Max-Age attribute values can be and (2) whether the two must be consistent. This resolves both by requiring:

1. The maximum attribute value to be 400 days in the future or less
2. The maximum set for Max-Age and Expires be consistent.

Why 400 days? The goal was to get close to 13 months so that functions one might perform annually (e.g., selecting insurance benefits for the next year) would work even as specific dates varied slightly. Since Expires deals in a specific date while Max-Age deals in delta-seconds, it seems ideal to select a value with an unambiguous meaning. If the cap were set at 13 months (instead of 400 days) in the future, the maximum TTL varies by the month it was set in and whether or not it's a leap year.

Who is compliant with this modification? Currently, only Safari sets a cap lower than 400 days (one week).

closes #1600

[chlily1]

I think this should primarily be up to the user agent, e.g. specified in the user agent's cookie policy (section 7.2). If the spec gives a specific limit, I think it should be a SHOULD rather than a MUST, since UAs are already doing their own thing.

See also section 7.4.

[chlily1]

I am still in favor of making this 400 day limit a suggestion (i.e. a SHOULD) rather than a hard limit, but I'll defer to y'all on that. Added some phrasing suggestions, and +1 to Martin's suggestions.

[miketaylr]

I am still in favor of making this 400 day limit a suggestion (i.e. a SHOULD) rather than a hard limit, but I'll defer to y'all on that.

Personally I think MUST makes sense as a max, with the existing carve-out that UAs can select something smaller if they want. So you end up with something like

let spec_max_days = 400;
let ua_max_days = 28;
let clamped = Math.min(Math.max(0, ua_max_days), spec_max_days);

[chlily1]

Sure, I don't feel strongly about it. If there's to be a hard upper bound on a limit, 400 days seems reasonable.

Separately, maybe there should be suggestion for a lower bound (a minimum capability that servers can expect but should not rely on, a la https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis#section-6.1).

Anyway, this lgtm if @sbingler and @miketaylr approve.

[arichiv]

I like the idea of a lower limit, how about seven days? One week seems like a reasonable expectation and there isn't a major browser violating that

[martinthomson]

7 days would probably break a lot of sites. I can imagine browsers that might adopt that policy, but the limit in the spec needs to allow for common usage and people expect logins to last out a 7 day absence. What Mike says here is entirely reasonable. Set a mandatory maximum (400 days is fine), let browsers adjust that downward according to their policies.

[sbingler]

For my own sake I want to clarify I'm how I'm interpreting this proposed change and if it aligns with everyone else.
(I'm not suggesting we use this phrasing in the spec, it's only for illustrative purposes.)

After this change is made:

• UAs MUST clamp the upper range of max-age to some value upper_max_age_limit.
• upper_max_age_limit SHOULD be equal to 400 days
• upper_max_age_limit MUST be greater than or equal to 7 days
  • (The number here is open to discussion but Safari already implements a 7 day limit for cookies set by JS.)

Sites are then free to set a cookie with a max-age anywhere from [0, upper_max_age_limit] (0 being shorthand for the UA's "earliest representable date and time"), and if they exceed the upper range the value will be revised down to upper_max_age_limit.

Does this sound agreeable? Does it align with everyone else's thoughts?

[mikewest]

This LGTM, modulo some pedantic nits.

[arichiv]

I'm down, but with a single edit @sbingler:

• UAs MUST clamp the upper range of max-age to some value upper_max_age_limit.
• upper_max_age_limit SHOULD MUST be less than or equal to 400 days
• upper_max_age_limit MUST be greater than or equal to 7 days

[sbingler]

I'm down, but with a single edit @sbingler:
UAs MUST clamp the upper range of max-age to some value upper_max_age_limit.
upper_max_age_limit SHOULD MUST be less than or equal to 400 days
upper_max_age_limit MUST be greater than or equal to 7 days

I guess my sticking point is this: if we want to allow UAs to adjust upper_max_age_limit, and it seems to me that we all want to allow this, why not make that clear with a SHOULD?
Using a MUST and relying on other parts of the spec to exempt that behavior seems odd to me and forces a reader to cross-reference other parts of the document when a quick glance at the max-age section should be enough imo.

[mikewest]

upper_max_age_limit MUST be greater than or equal to 7 days

Why? @martinthomson's suggestion that we "Set a mandatory maximum (400 days is fine), let browsers adjust that downward according to their policies." seems reasonable to me, and would allow this patch to address the concern actually expressed in #1600 around behavior at the upper limits. If a given browser wanted to cap max-age at 1 day, or 1 second, why would we restrict them from doing so?

[miketaylr]

+1 to @mikewest's comment, lower-bound requirements don't seem very useful to add to the spec.

[arichiv]

What if the lower bound was a SHOULD? I like the idea of communicating some reasonable minimum that servers might expect but not require