INFO: ASP Requires Session State to Maintain Static Cookies (184574)

MORE INFORMATION

The Active Server Pages developer needs to understand how cookies work in order to maximize performance and minimize unexpected results such as losing session state. Each request made to ASP will trigger the creation of a new SessionID cookie unless a Session variable is created in the requested page or there is a Session_OnStart event handler in the Global.asa file. By the same token, ASP creates unique SessionID cookies when .asp files are used as the source for frames in a FRAMESET.

These multiple SessionID cookies may affect performance. If a session is triggered by storing a scalar or object value to a session variable, but the user moves out of or to another ASP application and then returns, the original session object is lost. You can also control this unintended result by an informed Active Server Pages design strategy.

ASP sends a different ASPSessionID cookie (scoped to the application, which is the virtual directory for the requested .asp file) for each and every .asp file that is requested until Session state is triggered. Session state is triggered once something is stored in a Session variable (a scalar variable or an object instance), or the Session_OnStart event is fired in the application's Global.asa file, the SessionID is fixed for that user until the Session times out or is abandoned.

The reasons for this are that, by default, buffering is off for an ASP page. This means that HTTP headers (which contain cookies) need to be generated before any content (typically HTML) is sent out by the processing of the .asp file. In other words, an ASPSessionID cookie is placed in the HTTP headers just in case there is going to be Session state defined in the processing of the forthcoming .asp file.

If no Session state is defined, the next .asp file request has the same potential to start the Session by placing something in Session state (this makes a new ASPSessionID because no Session has been started prior to this request). If Session state is used, the ASPSessionID remains constant for the rest of the session.

NOTE 1: If the .asp page turns the Buffering property of the Response object on (that is, Response.Buffer=TRUE), ASPSessionID cookies are not sent out with each .asp file request until Session state is used. This is because the HTTP headers can be changed even after content has been produced. So, as noted in the preceding two paragraphs, the reason the ASPSessionID is created before the .asp file is processed is unnecessary when buffering is ON.

NOTE 2: If you do not plan to use Session state for any application, you may use the registry to turn it off for all applications.

NOTE 3: You can stub out the Session_OnStart event in the Global.asa file; that is, no code is necessary between the beginning and end of that subroutine.

NOTE 4: Under ASP 1.0b, additional difficulties can occur if full permissions are not given to the Global.asa file. If individual .asp files need finer access control lists, store them in subdirectories beneath the directory that contains the Global.asa file.

NOTE 5: ASP Hotfix 1.21.11 permits ACL restrictions on the Global.asa file. Contact Microsoft Technical Support if you feel that installing this hotfix is necessary. For a complete list of Microsoft Product Support Services phone numbers and information about support costs, please go to the following address on the World Wide Web:
In special cases, charges that are normally incurred for support calls may be canceled, if a Microsoft Support Professional determines that a specific update will resolve your problem. Normal support costs will apply to additional support questions and issues that do not qualify for the specific update in question.