W3C home > Mailing lists > Public > www-lib@w3.org > July to September 2001

Irony: Another apparent bug in cookie handling (libwww 5.3.3)

From: James D. Brown <jamesbrown@shopswell.com>
Date: Mon, 2 Jul 2001 13:17:08 -0400 (EDT)
To: www-lib@w3.org
Message-Id: <01070211165503.01719@franz.shopswell.com>
On the documentation page for cookie handling, 
http://www.w3.org/Library/src/HTCookie.html, there is a link to a Netscape 
specification for cookies: 

This page lists a specific date format for the EXPIRES field:

The date string is formatted as: Wdy, DD-Mon-YYYY HH:MM:SS GMT This is based 
on RFC 822, RFC 850, RFC 1036, and RFC 1123, with the variations that the 
only legal time zone is GMT and the separators between the elements of the 
date must be dashes. 

HTParseTime() is called in HTCookie_parseSetCookie to parse the time value 
into a time_t.  HTParseTime() (from HTWWWStr.c) supports three different date 

**    Wkd, 00 Mon 0000 00:00:00 GMT    (rfc1123)
**    Weekday, 00-Mon-00 00:00:00 GMT     (rfc850)
**    Wkd Mon 00 00:00:00 0000 GMT     (ctime)

The irony is that the code supports three formats for EXPIRES dates, but 
none of those formats matches the Netscape spec referred to in the 
documentation.  Unfortunately, the Perl CGI class's as_string method 
generates EXPIRES dates in the same format specified by Netscape.  This means 
expiration dates generated by the Perl CGI class cannot be parsed by libwww.  
You end up with a cookie that has no expiration date, and no notice from 
libwww that there was a problem parsing the date.

Am I missing something here?
James D. Brown, President, Shopswell, Inc.
Voice: 303-400-0480 - FAX: 303-400-7181
http://www.shopswell.com - jamesbrown@shopswell.com
Received on Tuesday, 3 July 2001 03:58:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:33:54 UTC