[RFC6265bis] Why Max-Age limitation is specified for User Agent ?

[Jxck]

in Section 4.1.2.2

The user agent MUST limit the maximum value of the Max-Age attribute. The limit SHOULD NOT be greater than 400 days (34560000 seconds) in duration. The RECOMMENDED limit is 400 days in duration, but the user agent MAY adjust the limit (see Section 7.2). Max-Age attributes that are greater than the limit MUST be reduced to the limit.

This section mentions Max-Age limitation.
But Max-Age is an attribute for Set-Cookie not for Cookie, and Set-Cookie is sent by Server not Client.
So I'm wondering why this section is written for "User-Agent" not "Implementation".

It can be considered as "Server could send any max-age, but Client will trim it to < 400day", but in that case, that recommendation is not for "Max-Age" attributes itself, but for lifetime management for implementation.

The RECOMMENDED limit is 400 days in duration

if this recommendation is for Max-Age attributes, it'll apply not (only?) for User Agent but for Server. So it should be use not "User Agent" but "Implementation".

[Jxck]

for more background: honojs/hono#2762

This is an issue for server side framework "Hono". It restricts max-age shorter than 400day according to RFC recommendation.
Because this framework respects modern best practice for web development by default.
But the developer issues that "400days limitation is for User-Agent, not for server" and requested to remove restriction.
And I'm wondering why the draft mentioning Max-Age recommendation is for User-Agent when checking it.

[miketaylr]

I'm not sure I agree that removing any mention of the user-agent in the Set-Cookie section is a better outcome. IMHO, it's useful to consider the client even in the context of server requirements.

This is an issue for server side framework "Hono". It restricts max-age shorter than 400day according to RFC recommendation.

That seems like a valid choice for the framework. I'm not sure I would make the same choice, but frameworks like to be opinionated, and I can see the logic behind the thinking. I don't see how this is a bug in the draft.

[Jxck]

IMHO, it's useful to consider the client even in the context of server requirements.

I'm not against that.
but please think it simply, this section is for "Max-Age attributes", and who sends "Max-Age" is SERVER.
So RECOMMENDATION should given for server, isn't it ?

[sbingler]

Hi,

Both the Max-Age and Expires are ways for the Server to specify the maximum amount of time the Server would like the cookie to exist. It's an upper bound. UAs can, and frequently do, remove cookies before the server specified time and this is allowed (and sometime encouraged) by the spec.

I see the UA's 400 day recommendation as an application of this principle.

It can be considered as "Server could send any max-age, but Client will trim it to < 400day"

That's the correct interpretation.

but in that case, that recommendation is not for "Max-Age" attributes itself, but for lifetime management for implementation.

The spec is communicating that cookies that specify a longer lifetime than "session" should have that lifetime limited. It does that by saying that max-age attributes should be limited. The same limit is applied to Expires.

Ultimately the spec is giving instructions on how UAs should behave. This behavior will obviously affect Servers but it is not for Servers.

That seems like a valid choice for the framework.

I agree with @miketaylr. Frameworks are free to apply whatever limit they like.

[Jxck]

In that case, what cause misreading is lack of specifying "received" for Max-Age.

- The user agent MUST limit the maximum value of the Max-Age attribute.
+ The user agent MUST limit the maximum value of the received Max-Age attributes values.

- Max-Age attributes that are greater than the limit MUST be reduced to the limit. 
+ Received Max-Age attributes value that are greater than the limit MUST be reduced to the limit by user agent.

And mentioning that this recommendation is not for server is also make the spec clear for me.

[sbingler]

I think a better option would be to move the paragraphs to a more UA focused section. I'll work on a PR