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