RE: HTTP State Management Mechanism (Rev1): EndSession attribute

The suggestion that
>     - the users browser is up to date enough to support this

Does not seem to apply.  This is a specification for a new type of cookie,
defined by Set-Cookie2, and there is no guarantee that the browser
will support the Set-Cookie2, least of all one of the attributes.  For those
browsers that do support Set-Cookie2, the EndSession attribute would
be entirely optional.  The specification would only define how the attribute
is processed *if* implemented.

As for
>     - the client system will not crash

Any brwoser that crashes is coded incorrectly.  Browsers are supposed to
ignore headers they do not recognize.  From the draft for
HTTP State Management Mechanism (Rev 1) dated March 19, 1997
"The user agent should ignore attribute-values pairs whos attribute
it does not recognize."

On the issue of security, here again, the draft is fairly clear
"This state management specification therefore requires that a user
agent give the user control over such a possible intrusion, although
the interface through which the user is given this control is left 
unspecified."



On Monday, April 28, 1997 7:37 AM, Scott Lawrence [SMTP:lawrence@agranat.com] 
wrote:
>
> >>>>> "MG" == Michael Giroux <mgiroux@worldnet.att.net>:
>
> MG> I have reviewed the current proposal for State Management, and
> MG> would like to suggest one additional cookie attribute that would
> MG> be extremely useful for inTRAnet environments.
>
> MG> Specifically, I would like to suggest a new attribute that will
> MG> specify a URL to be submitted if the user closes the browser while
> MG> the cookie is still valid.
>
>   I'm afraid I must agree with Joshs' critique; especially the
>   security implications.
>
>   In addition, because you can't assume among other things that:
>     - the users browser is up to date enough to support this
>     - the user has not configured the browser to disable this
>     - the client system will not crash
>
>     ... your server application must still have all the support for
>   timing out the session and cleaning it up anyway, and good system
>   design would need to allow for the worst case (the power fails and
>   comes back - all the clients die, then come up and try to create new
>   sessions - and then the power fails...), so the attribute looks to
>   me like an easy way to assume you've solved a problem you really
>   have not.
>
> --
> Scott Lawrence           EmWeb Embedded Server       <lawrence@agranat.com>
> Agranat Systems, Inc.        Engineering            http://www.agranat.com/

Received on Monday, 28 April 1997 20:14:10 UTC