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

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

From: David W. Morris <dwm@xpasc.com>
Date: Wed, 30 Apr 1997 22:59:12 -0700 (PDT)
To: Daniel DuBois <ddubois@pobox.com>
Cc: Michael Giroux <mgiroux@worldnet.att.net>, http-wg@cuckoo.hpl.hp.com
Message-Id: <Pine.SOL.3.95.970430224258.28246C-100000@shell1.aimnet.com>


On Thu, 1 May 1997, Daniel DuBois wrote:

> On Wed, 30 Apr 1997 21:35:06 -0700, Michael Giroux
> <mgiroux@worldnet.att.net> wrote:
> 
> >offering alternatives.  As you indicated, I have identified a problem.
> >It would be nice to get some discussion on it.
> 
> Seems to me the problem is a social one, not a technological one, so use a
> social solution.  Find a way to more strongly encourage end-users to
> logout.  For instance, automatically send them warning emails if they
> time-out instead of logout.  Flash big warning messages to them at next
> logon.  Cut their pay.  Whatever.

Surely you jest!  We have a technologically flawed protocol and you
propose that a social solution be applied. The stateless nature of HTTP
has some positive implications and some negative implications. The
complete lack of any potential for automatic detection of user disconnect
is a major negative problem for folks building interactive applications on
top of HTTP.  I really don't see any security issue with a server
registering a disconnect URL with a user agent. I think a GET method
should be used to keep the protocol simple and stress the restriction on
side-effects. If the URL can only be sent back to the server which
registered it and if the registration can only arrive with an explicit
user initiated transaction and not an indirect transaction. Furthermore,
define the URL as having a 'don't care' response ... as in send on a best
effort basis and close after the status is received or whatever but ignore
the response content, etc. Define some conditions which represent session
termination ... UA is exited, user backs up in the history list and starts
down a new path, perhaps the user types a new URL manually. Essentially,
a 'session' is over when the user can no longer click on links/buttons 
within the application context.

My perspective is that there is certainly a problem here. There are safe
technological approaches for improving the situation but I'm not really
motivated to spend group time working on a solution given the large list
of pressing issues. A good topic for HTTP-2-WG, in part because I would
rather see a new method like DISCON to convey the logical disconnect and
in part because this group is supposed to finish sometime soon.

Dave Morris
Received on Wednesday, 30 April 1997 23:00:18 EDT

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