Active Server Pages (ASP) uses HTTP cookies to maintain session state.Under certain conditions, the value of these session cookies may change.This article describes conditions under which session cookies aregenerated and how to ensure that static cookies are created.
The Active Server Pages developer needs to understand how cookies work inorder to maximize performance and minimize unexpected results such aslosing session state. Each request made to ASP will trigger the creation ofa new SessionID cookie unless a Session variable is created in therequested page or there is a Session_OnStart
event handler in theGlobal.asa file. By the same token, ASP creates unique SessionIDcookies when .asp files are used as the source for frames in a FRAMESET.
These multiple SessionID cookies may affect performance. If a session istriggered by storing a scalar or object value to a session variable, butthe user moves out of or to another ASP application and then returns, theoriginal 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 andevery .asp file that is requested until Session state is triggered. Sessionstate is triggered once something is stored in a Session variable (a scalarvariable 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 ASPpage. This means that HTTP headers (which contain cookies) need to begenerated before any content (typically HTML) is sent out by the processingof the .asp file. In other words, an ASPSessionID cookie isplaced in the HTTP headers just in case there is going to be Session statedefined in the processing of the forthcoming .asp file.
If no Session state is defined, the next .asp file request has thesame potential to start the Session by placing something in Session state(this makes a new ASPSessionID because no Session has been started priorto this request). If Session state is used, the ASPSessionID remainsconstant 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 fullpermissions are not given to the Global.asa file. If individual .asp filesneed finer access control lists, store them in subdirectories beneaththe 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.