The Session object of ASP (Active Server Pages) technology is used to store private information of users during conversations. The variables and objects defined in the Session object of the current user can be shared between pages, but cannot be accessed by other users in the application. Therefore, when developing web applications with ASP, the Session object can be used to save and track user status information.
The Session object has a very important property: Timeout, which is used to set the time the session object can remain inactive before the session resource is released (the default value is 20 minutes). When the time value set by the Timeout property is exhausted, the session resource will be released. Destroy the Session object through the Timeout attribute, avoiding the Session object being generated in the server without restrictions and protecting the server resources. However, in actual network development, it is often encountered that the application process cannot be completed normally due to the failure of the Session object and the loss of user status information.
Although the strategy of releasing resources using the Timeout attribute is for the purpose of protecting the server, the unpredictable failure of the Session object has become a disadvantage in developing applications. Therefore, in the development of actual application, the problem of Session object failure must be solved.
Traditional solutions
The existing solutions are all to use server-side methods to solve the problem of Session object failure. Typical treatment methods are divided into two categories: treatment before failure and treatment after failure.
Processing before failure refers to transferring and other processing of variables before the Session object has expired to prevent problems before it happens. A typical solution is to set a timer in the application, trigger the timer 5 minutes before the Session object fails, and then reset the various variables and objects of the Session object. This method adds additional load to the server because the timer must be maintained in real time on the server side and the program must be ensured to be active throughout the session.
The processing after failure refers to prompting the user to process immediately after the Session object expires. A typical solution is to save breakpoints on the server side after the Session object fails, and prompt the user to log in again and continue to complete the work. This method is simple to implement, but is often complained and criticized by the end users because of the incomplete automatic recovery of breakpoints and the complexity of the re-login process.
In response to the shortcomings of the above two types of solutions, in programming practice, the author combines the characteristics of the cookie object and uses the method of jointly accessing session-level variables on the client, which not only avoids the additional demand for server resources, but also solves the problem of The problem of breakpoints not being automatically restored, and it also eliminates the trouble of logging in again.
New solution
A cookie object is a small packet of information that stores data about the current user, which can be passed between the browser and the web server. In web applications, cookies provide a mechanism for tracking and recording each user location. One of the most common uses of cookies is to save the time and date of the last web page to be visited in a web application or the URL to be visited.
Usually, cookie objects are stored in the Cookies subdirectory in the client Windows system directory as files. The information data stored in the cookie object can be stored for a long time, so session-level variables can be backed up in the cookie object. After the Session object is invalid, breakpoints can be automatically restored by retrieving and using the information in the cookie object.
A cookie object has the following properties:
●Expires: Set the date when the cookie object expires;
●Domain: determines the transmission of the cookie object as a member determined only by the Domain attribute;
●Path: Determine the delivery path of the cookie object;
●Secure: To clarify whether the cookie object is safe;
●HasKeys: Returns whether the cookie object contains multiple values.
If the Expires property of the Cookie object is not explicitly defined, the Cookie object will expire at the end of the user session.
Read and write objects through Request collection and Response collection in ASP. The syntax for writing variables to a cookie object is as follows:
Response.Cookies(cookie)[(Key)|.attribute] = value
Where, the cookie is the cookie file name, the Key indicates a dictionary element, the attribute is a specific nature of the cookie, and the value is the value assigned to the cookie. For example, to create a cookie called MyHobby and assign its value to: BasketBall, use the following syntax:
<%Response.Cookies(MyHobby)=BasketBall %>
The method of reading a cookie object on the client machine is as follows:
Request.Cookies(cookie)[(Key)|.attribute]
Among them, the cookie is the name of the requested cookie, the Key is the subscript of the subkey value, and the attribute is used to indicate the cookie attribute. For example: To extract information from a cookie called MyHobby and write its value to the page, use the following syntax:
<% Request.Cookies(MyHobby) %>
It should be noted that the HTTP page header cannot be written to a cookie object after the HTTP page has been sent to the requesting browser. In other words, cookie information cannot be sent to the browser after any HTML identifier is sent to the browser.
Specific implementation
The following is a chat room implementation based on ASP technology to introduce how to deal with the issue of Session object variable failure.
●Initial session-level variable before the user logs in: UserName (used to store the login username).
<%Session(UserName)=%>
//Initialize the cookie object
<% Response.Cookies(UserName)= %>
●When the user logs in, set session-level variables and back up to the client cookie object.
<%userName=Trim(Request.For(UserName))%>
<% Session(UserName)=userName %>
//Back up session-level variables to client cookie object
<% Response.Cookies(UserName)=userName %>
●When the user speaks, the session-level variable is read. If the variable has expired, the attribute value of the session-level variable is restored by reading the cookie object.
<% userName=Session(UserName) %>
//If the variable has expired, search the client cookie object
<% if userName= then %>
<% userName=Request.Cookies(UserName) %>
<% if userName= then %>
//If the user enters the chat room without logging in, the attribute value of the cookie object is empty. At this time, the user is prompted to have an error and turn to the user login page
<%Response.Redirect Error.html %>
<% else %>
//Restore this session-level variable from the cookie object
<% Session(UserName)=userName %>
<% end if %>
<% end if %>
●When the user exits the chat room, clear the session-level object and the cookie object.
<%Session(UserName)=%>
//Clear the attribute value of the cookie object to avoid users entering the chat room without logging in
<% Response.Cookies(UserName)= %>
The above code is run and passed in Windows NT 4.0 + IIS 4.0 + IE 5.0 environment.
Summary
The method of accessing session-level variables in the client is simple and practical, and can effectively avoid problems such as forced login by users. It is also a better way to solve the failure of Session objects.