Re: state management sub-group status

At 09:46 pm 1/19/96 -0500, Dave Kristol spake:
>The state management sub-group has held several telephone conferences to
>discuss issues.  We have agreed to use the Netscape Cookie syntax, and we

  <snip>

>the words to express the rules that govern that behavior.  Lou Montulli
>(Netscape) has volunteered the services of one of their tech. writers to
>work on a specification.  We now await a draft specification from them so

   I look forward to seeing this. I was disappointed by Netscape's 
implementation of their persistent cookies. I sent them email with 
a discussion of the shortcomings and never got a reply (actually, 
I've never gotten a reply to any of my email to Netscape). 

 # # # 

   In particular: (excerpted from the Cookies chapter in my book)

7.6.1 Top-Level Domain Safeguards

The safeguards that prevent a cookie from being associated with a 
top-level domain also prevent it from being used with many valid domains 
outside of the United States. For instance, a domain named 
"foo.uk" would be a valid, non-top-level, domain in Great Britain, 
but it fails the test of having the minimum three periods designed to 
protect against top-level domains like "va.us" and therefor will 
not work with Netscape cookies. 

7.6.2 The Expires Tag

Expiration of the cookie is determined by comparing the expiration date and 
time to the local time in the user's system, which may have little if any 
relation to the time of the host. In other words, if the user's clock is 
off by a day, as many are, the cookie may never be created in the first 
place, or may disappear at an inconvenient time. This feature would be more 
useful if Netscape would use the time transmitted by the server instead. 

Another problem with the implementation of the expires tag code is 
the way that Netscape parses the time. The system requires that the time be 
entered in GMT--which in itself is not a problem. But if the time string 
specifies another valid time zone, Netscape goes ahead and uses the string 
as if it where GMT. It ignores strings that use a bogus time zone 
(like QQQ), but will accept a time string without any time zone specified 
(again assuming GMT). This behavior could make it very difficult to debug 
a program that erroneously uses a time zone besides GMT. 

(Contrary to the documentation, it will accept GMT, UT or UTC as the time 
zone indicator, but not the military equivalent, Z.) 

 # # # 

   The other problem I have with this implementation is that there 
is no way to set up a session without a round-trip, and there is currently 
no way to generate a round-trip without requiring some user interaction. 
In other words, I would like to be able to set a cookie and read it back 
(necessary to confirm that the browser installed the cookie) with just 
headers, but attempts to do this with Netscape result in the "page has 
no data" dialog--and no response at all from the browser. 

   So, some "cookie-only" response code (or a generic "header-only") 
would help the usefulness of cookies for maintaining sessions. 

   There does not seem to be an appropriate response code for this 
in draft-ietf-http-v11-spec-00.txt, perhaps a 100-level response 
code would be appropriate.  

   BTW, as they are right now, I see no advantage to Netscape Cookies 
over hidden form-fields, other than their persistence. It would be 
really nice to be able to use them for short-term (i.e. single-session) 
session managment. 


+--------------------------------------------------------------------------+
| BearHeart / Bill Weinman | BearHeart@bearnet.com | http://www.bearnet.com/ 
| Author of The CGI Book -- http://www.bearnet.com/cgibook/

Received on Sunday, 21 January 1996 11:41:32 UTC