www-apache-bugdb mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Rigney <patr...@evocative.com>
Subject Re: [Fwd: mod_usertrack/1278: date format for cookies is not compliant with RFC..causes errors]
Date Tue, 21 Oct 1997 23:00:03 GMT
Chris Tamblyn wrote:
> [Patrick, anything to add...?]
>     ---------------------------------------------------------------
> Subject: Re: mod_usertrack/1278: date format for cookies is not compliant with RFC..causes
> Date: 21 Oct 1997 07:41:10 -0000
> From: rse@hyperreal.org
> To: apache-bugdb@apache.org, cjt@evocative.com, rse@apache.org
> Synopsis: date format for cookies is not compliant with RFC..causes
> errors
> State-Changed-From-To: open-analyzed
> State-Changed-By: rse
> State-Changed-When: Tue Oct 21 00:41:09 PDT 1997
> State-Changed-Why:
> 1. the current mod_usertrack (1.2.4 and 1.3b2) only
>    creates Cookies according to Netscapes "old" Cookie
>    proposal, because the "new" one (RFC 2109) has
>    "Max-Age" instead of "Expires".
> 2. While Netscape says in their proposal under
>    http://www.netscape.com/newsref/std/cookie_spec.html)
>    the date format is ...DD-MM-YYYY... and this follows
>    RFC822, etc.

For reference, I originally thought the dashes vs. spaces was the
issue.  Further testing has revealed that this is not the case.  There's
still a problem, so please read on...

> So, it is not clear what the actual format is, because
> RFC822 says ...DD MM YYYY.., the proposal says
> ...DD-MM-YYYY... and Apache uses ...DD-MM-YY...
> But either way Apaches current format is more like Netscapes
> one than the one from RFC822. So, when mod_usertrack

Well, no, it doesn't.  It (Apache) uses the RFC1123 (four-digit year
with spaces) format, except in mod_usertrack.c (base version 1.2.4),
where there is "custom" date formatting code that inserts dashes between
elements and has a two-digit year.  The function gm_timestr_822()
inserts spaces, and is used everywhere in the code _except_
mod_usertrack.c for some reason.

Netscape's document specifies a four-digit year, and this seems to be
the point of issue.  Apache is generating a two-digit year in

Netscape 3.01 on the Mac wouldn't parse the Set-Cookie header with
two-digit years, but does correctly parse the header when the date has a
four-digit year.  I can only surmise that internally it's parsing the
two digit year "98" as 0098, and instantly expiring the cookie (hey,
it's almost 2000 years old!).  I'm not sure what other browsers behave
like this, but I'll try to take some time to figure it out.

> should be fixed, then better to DD-MM-YYYY instead of
> RFC822's variant, I think. Or even better: mod_usertrack
> should use the format of RFC 2109 when it becomes a
> valid draft and browsers support it.

So we agree! Your example shows a four-digit year. ;-)  The fix to
mod_usertrack is to extend the year to four digits, either in the
existing code or by calling gm_timestr_822().  The latter has the side
effect of changing the separator to spaces, but that makes Apache
consistent with itself in other headers ("Date" and "Expires" for
example), and also with Netscape Enterprise 2.01 and 3.0, and Microsoft
IIS 3.0, all of which are good company.

As for RFC2109, if you're going to make Apache send max-age instead of
expires, please consider adding a config directive to control that. 
>From my perspective (ISP), the server needs to be compatible with a huge
base of browsers.  I think your key point is "when ... browsers support
it"... I know a lot of people still using ancient versions of Netscape
and MSIE, and they're in no hurry to upgrade (especially to IE 4 ;-). 
Bottom line, my customers could care less about RFCs; they care about
what works.


View raw message