- From: Michael Giroux <mgiroux@worldnet.att.net>
- Date: Sat, 26 Apr 1997 21:22:53 -0700
- 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 UTC