Subject: [http-state] Max-Age

From: Adam Barth <[email-masked]>
Date: Mon, 17 Aug 2009 09:29:20 -0700

The test suite has revealed that the Max-Age cookie attribute is supported by

Firefox
Safari
Chrome
Opera
CURL

and ignored by

Internet Explorer

We have two decisions to make:

1) Should we include Max-Age in the user agent conformance section?

It seems clear that Max-Age has wide enough deployment that new user
agent implementors will want to include support.  Therefore, I think
we should include Max-Age in the user agent conformance section.

2) Should we include Max-Age in the server conformance section?

I also think that we should include Max-Age in the server conformance
section because Max-Age has broad enough implementation among user
agents (i.e., all but IE) and is sufficiently incrementally deployable
that I think it's possible that including it in the spec will cause
Internet Explorer to adopt the attribute, which would improve
interoperability.

Of course, we should also include Expires, which is supported by every
major implementation.  We might also want to include a note that at
the time of this writing, the Expires attribute has been implemented
by more user agents.

Adam

---

From: Dan Winship <[email-masked]>
Date: Mon, 17 Aug 2009 14:26:48 -0400

> 2) Should we include Max-Age in the server conformance section?

I don't think so; if we say "sending a cookie with Max-Age=0 will cause
the cookie to be deleted", then we're basically lying. And saying
"sending a cookie with Max-Age=0 will cause the cookie to be deleted as
long as you also include an Expires attribute containing a date in the
past" would be silly.

Max-Age is a better design than Expires in several ways (parsability,
obviousness of the "expire now" syntax, ability to be used by clockless
servers). But for now, it's not interoperable, so that's what we've got
to work with.

We can say that user agents SHOULD/MUST be able to parse Max-Age, but
even if IE9 ships with support for it, there would still be IE6/7/8
users around for a while after that, so it will be a while before
servers can depend on Max-Age working.

-- Dan

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 19 Aug 2009 08:48:26 +0200 (CEST)

On Mon, 17 Aug 2009, Adam Barth wrote:

> It seems clear that Max-Age has wide enough deployment that new user agent 
> implementors will want to include support.  Therefore, I think we should 
> include Max-Age in the user agent conformance section.

Yes, a client-side cookie implementation cannot work very well in the wild 
without support for max-age. Although of course ignoring max-age only has the 
very minor side-effect that the cookies will be treated as "session cookies" 
instead of getting stored with a set life-time. (At least that's my assumption 
how a non-understanding client would behave.)

> 2) Should we include Max-Age in the server conformance section?

I think I'm with Dan on this. As not all clients support max-age but they all 
support expires, we're much better off simply saying that expires is the 
preferred way. With all its downsides. After all, it's still working.

This is another issue of as-it-is-today or how-we-prefer-tomorrow. AIIT is 
clearly messier than HWPT, but if we document HWPT as MUST then we willingly 
decide that N% of the web browsers are non-compliant. This will then strike 
back when server implementors rather stay compliant with their IE6 users and 
simply ignore the spec. And we're back to where RFC2109 and 2965 are.

So I say max-age support is a SHOULD in clients, but servers are adviced to 
send expires to time out cookies.

-- 

  / daniel.haxx.se

---

From: Adam Barth <[email-masked]>
Date: Wed, 19 Aug 2009 00:13:55 -0700

On Tue, Aug 18, 2009 at 11:48 PM, Daniel Stenberg<[email-masked]> wrote:
> This will then strike

I'm glad we're taking the experiences of 2109 and 2965 to heart.  I
think we might be swinging the pendulum slightly too far in the other
direction.

On Tue, Aug 18, 2009 at 11:20 PM, Ian Hickson<[email-masked]> wrote:
> We're documenting (or should be documenting, IMHO) what all
> implementations are going to converge on. That means describing what they
> do when they do the same thing, and considering differences to be bugs for
> which we are to find solutions that are acceptable to implementors.

I think where 2109 and 2965 went wrong is they added requirements that
implementations couldn't converge on without serious compatibility
problems.  For example, on this issue, 2109 specs Max-Age but ignores
Expires entirely.  An implementation that follows this advice will be
wildly unable to interoperate with servers.

On Tue, Aug 18, 2009 at 11:48 PM, Daniel Stenberg<[email-masked]> wrote:
> Yes, a client-side cookie implementation cannot work very well in the wild without
> support for max-age.

[...]

> So I say max-age support is a SHOULD in clients

These two statements appear to be in conflict.

In any case, we can fine tune SHOULD versus MUST when the spec is more complete.

Adam

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 19 Aug 2009 09:23:18 +0200 (CEST)

> These two statements appear to be in conflict.

Right, sorry, I was expressing myself bit clumsy.

The problem for a *generic* client is that it wants to be generically fine 
against all servers and for that you need max-age support.

But the world is not made only by this generic kind of clients, it is also 
very often built up by servers crafted to work with a specific client and 
clients made to work fine only with some servers. Or just having the server 
detect which client it is that speaks and adjust its responses for it.

So, IE6 works fine (cookie wise at least) against a large amount of servers 
that don't use max-age, but it's not working fine with servers that use 
max-age only.

-- 

  / daniel.haxx.se

---

From: Dan Winship <[email-masked]>
Date: Wed, 19 Aug 2009 10:34:00 -0400

> think we might be swinging the pendulum slightly too far in the other

Well, my feeling is, the absolute worst case on the "too compatible"
side is "we produce a spec that describes the maximally interoperable
subset of real-world cookies, and nothing else", which is a pretty good
outcome. Whereas if we stray too far onto the "too many changes" side,
we might accidentally cross into the RFC 2965 zone of total irrelevance.
So it's just safer to err on the too-compatible side for the initial
spec (or at least for the normative parts of the initial spec).

> problems.

Yes, but I think another big one is that they ignored the fact that
cookies *already worked*. If you tell web developers "you can either use
Expires, which works everywhere, or you can use Max-Age, which does
*exactly the same thing* as Expires, but does not work everywhere", then
there's no reason they'd use Max-Age.

>> Yes, a client-side cookie implementation cannot work very well in the wild without

Well, you need to either support Max-Age OR allow cookies to have
unrecognized attributes. You do not need to actually *understand*
Max-Age, as demonstrated by IE.

> In any case, we can fine tune SHOULD versus MUST when the spec is more complete.

I feel like we want clients to support Max-Age, but I don't feel like
it's reasonable to encourage servers to send it. And if servers aren't
sending it, then clients aren't going to get much testing of their
implementations of it, which makes me feel like maybe we shouldn't
recommend it there either. I could probably be convinced either way on
this though (for the client side).

(Tying into the other mail I just sent, in the UA conformance thread; we
could include Max-Age in the client-side SHOULD grammar, but not in the
MUST grammar [it would just be treated as an unrecognized attribute in
the MUST grammar]. Though we still have the problem of what to recommend
about its use; we really would have to say "at the present time, servers
SHOULD NOT send Max-Age unless they also send Expires".)

-- Dan

---

From: "Anne van Kesteren" <[email-masked]>
Date: Wed, 19 Aug 2009 16:51:41 +0200

> spec (or at least for the normative parts of the initial spec).

As long was we communicate with the vendors of clients and create a test suite I do not think that would happen. Besides, if we do the reverse engineering properly we'll always match one or more clients.

> there's no reason they'd use Max-Age.

Right, we should define handling for both.

-- 
Anne van Kesteren
http://annevankesteren.nl/