W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

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

From: Michael Giroux <mgiroux@worldnet.att.net>
Date: Mon, 28 Apr 1997 19:05:07 -0700
Message-Id: <01BC5407.1AD80440@mgiroux@worldnet.att.net>
To: 'Scott Lawrence' <lawrence@agranat.com>
Cc: "'http-wg@cuckoo.hpl.hp.com'" <http-wg@cuckoo.hpl.hp.com>
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.

This is precisely why the browser needs to have configuration
options for processing.

I fail to see how adding an attribute to the specification causes the 
problems
that you envision.  First, the browser is not required to implement support.
Second, this is for inTRAnet applications where sites will have considerable
control over user configurations.  Finally, if the specification suggests 
that
browsers should ignore such an attribute by default, then it seems tough to
make any assumptions about it.


>   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

This feature is intended for inTRAnet applications.  In this case, the
browsers *will* be up to date, and the site will dictate how to configure
the browsers. Again, inTRAnet.  These are corporate applications,
behind the firewall, inside the glass house, ...
Corporate policy will mandate that the proper browser is installed,
and that it is configured appropriately.


>     ... 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.

As I said, the intent is for inTRAnet applications where the site 
administration
has considerable control over the user environment.  True that the server 
will
have to program for timeouts, but this should not preclude the workgroup from
considering features that allow a site to improve on the situation.  It seems 
a
bit shortsighted to leave a feature out of the specification just because it
might cause a security problem.  If all specs took potential risks into 
account,
we would never have been able to do file io or dereference pointers in C.

Michael Giroux
Received on Monday, 28 April 1997 19:11:19 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:35 EDT