Re: [http-state] draft-ietf-httpstate-cookie-05 posted

["Paul E. Jones" <[e-mail]>]

Adam,

> > If a UA today would do something strange, the UA needs to be fixed.
> 
> The spec already requires UAs to handle this case.  As I said above,
> this language is in the spec as advice to help servers deal with
> existing UAs that do not comply with the spec.  By definition, the UAs
> we're concerened about here cannot be fixed.

But, are there UAs that truly have a problem with the cookie expiration
time?  If so, this is a bug and we should not change the protocol (which
this recommendation does, in effect) due to such an isolated bug.  Perhaps
it might be noteworthy to have in a blog somewhere that browser X has this
limitation, but it does not seem appropriate for the standard, because I
would not want to encourage application server developers to impose some
artificial limit like this.
 
> > I'm concerned with inserting language that requires behavior to try
> to overcome
> > issues with user agents.
> 
> That's how the web works.

I don't understand what you mean by this statement.
 
> > Do such issues exist in practice?  If so, we ought to fix the
> browser.
> 
> I haven't tested browsers, but I do know of these sorts of issues
> occurring in HTTP caching headers, for example in IE6.

While IE6 still clings to corporate walls, me, you, and everybody --
including Microsoft -- agrees that it's long past time for this browser
release to disappear.  And, I believe the corporate world has received that
message and I am seeing a decline in IE6 usage.  This specification will
provide guidance for years (perhaps decades), so we ought not force server
application developers to consider (for too long) such interop issues.  This
is but 1 of many, many things people have to deal with for IE6 -- if it is
even a problem at all.  I would have guessed that MS would have changed any
future date in 0x7FFFFFFF if they do use time_t.  And, that's OK.
 
> > Also consider that it's not the web server that will generate
> cookies, but
> > many thousands of application developers will create cookies and
> specify
> > expiration dates.  There are just a handful of browser vendors.
> 
> So?

There will be thousands of web developers who do not look at this spec.  I
expect every browser vendor will have a team that reads this spec.  With
just a few browser vendors and everybody reading the spec and understanding
that dates might be years like 5243, then I would expect a greater chance of
handling the date in some "sane" manner.  And, that "sane" manner might be
to not use a 32-bit time_t. 
 
> > When one of these thousands of app developers passes an expiration
> date of
> > 2050 over the wire and a browser breaks, do we blame the application
> > developer who composed a proper date or the browser vendor who didn't
> give
> > the date reasonable treatment? This language suggests we blame the
> app
> > developer, but I don't think that's where blame should be placed.
> 
> I'm not very interested in the blame game.  The spec requires UAs to
> handle these far-future dates in a reasonable way.  The spec also
> recommends servers avoid using these dates because of interoperability
> issues.  If we find a case where the server is using such a date and
> the UA is having trouble processing it, I'd recommend that both the
> server and the UA change.

And both might change.  Application developers, as I mentioned, already work
around all kinds of UA inconsistencies.  Even so, the text provides guidance
to web server developers to NOT use dates beyond 2036 (which I assume you'll
change to 2038) to maximize compatibility.  This is like a stamp of approval
for UAs to not support longer dates.

I'd be O with something like:
It should be noted that some older user agents that utilize a 32-bit signed
time_t data type to store the cookie expiration time might not properly
support dates much beyond 2037.  If support of such legacy user agents is
important, application developers should take care to use sane-cookie-dates
before 2038.

Perhaps the word "legacy" is too strong and could be replaced with "older".
But, I think that captures your intent to provide caution, but also
highlights the fact that it's not desirable for UAs to have this limitation.

Paul