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

HTTP State Management Mechanism (Rev1): EndSession attribute

From: Michael Giroux <mgiroux@worldnet.att.net>
Date: Sat, 26 Apr 1997 21:22:53 -0700
Message-Id: <01BC5289.3CA56240@mgiroux@worldnet.att.net>
To: "'http-wg@cuckoo.hpl.hp.com'" <http-wg@cuckoo.hpl.hp.com>
I have reviewed the current proposal for State Management, and would like to 
suggest one additional cookie attribute that would be extremely useful for 
inTRAnet environments.

Specifically, I would like to suggest a new attribute that will specify a URL 
to be submitted if the user closes the browser while the cookie is still 
valid.

This new attribute would be used to make sure that server resources are freed 
if the user terminates the browser without logging off from the application.

The situation I am addressing is the case where an application is implemented 
on a mainframe or very large Unix server.  The application requires a logon, 
and maintains some context between interactions with the browser.  The cookie 
allows the application to select the correct context.  The following issues 
will exist in such an application.
1. 10,000 or more users connected.
2. The application *WILL* contain a logout button that users *should*
   press when disconnecting.
3. The application *WILL* have a timeout mechanism to expire sessions that
   have not been active.
4. All users are behind corporate firewall, and employees of the company.

The problem that occurs is that some users do not press the logout button. 
 When this occurs, the mainframe must hold the resources associated with the 
context until the timeout occurs.  In some cases, this involves holding 
database resources and memory resources that impact overall system 
performance.  A malicious user might even mount a denial of service attack by 
starting many sessions.

In order to notify the server that the browser has terminated, and 
consequently will not be sending a logout anytime soon, I would like to 
propose a new cookie attribute that would be processed by the browser during 
shutdown.  The attribute would specify a URL to be submitted that would tell 
the mainframe server to terminate the session and free associated resources.

I recognize that such a mechanism will not be acceptable to users in general. 
 However, for the corporate inTRAnet environment, it is important to be able 
to manage resources, and the availability of such an attribute would 
significantly improve availability and performance of a server.  As 
corporations replace 3270 terminals with browsers, this type of mechanism 
will become more important.

There are a number of very good reasons why one might not want the browser 
executing such a cookie.  Privacy issues, connection statistics, and many 
more.  Performance is another factor.  If a browser collected several of 
these cookies, it could take a while to shut down.  Recognizing these issues, 
I suggest that the user have full control over the proposed EndSession 
attribute.  The user should be able to configure a browser to act on this 
attribute in any number of optional ways:
a. ignore the attribute completely
b. notify user when EndSession attribute is received
c. notify user when EndSession is about to be executed during browser 
shutdown
d. process EndSession only for specific "trusted" sites, thus allowing 
corporate
   applications to use EndSession, while rejecting the attribute from general 
internet sites.

There may be other optional modes of processing as well.

Summary:
The EndSession attribute would allow a site to *ask* the browser to execute a 
logoff url if the browser is shut down.  This attribute attempts to solve a 
very specific problem for large scale corporate inTRAnet applications.  I 
would hope that this attribute is executed very rarely.  Normally, users will 
end a session explicitly by using an application LOGOFF button. The user 
should have full control over how a browser processes such an attribute.

Finally, the attribute name "EndSession" is only a suggestion.  The working 
group may have a much better name.  The proposed user controls at the browser 
level are also only suggestions.  The wg may have a better solution for user 
management.

Michael Giroux
Received on Saturday, 26 April 1997 21:33:41 EDT

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