Difference between session and cookie

This article uses asp.net as an example to introduce the differences and connections between sessions and cookies. For more information, see.

Specifically, the cookie mechanism adopts the client-side persistence scheme, while the session mechanism adopts the server-side persistence scheme. At the same time, we can also see that because the server-side persistence scheme also needs to save an identifier on the client, the session mechanism may need to use the cookie Mechanism to save the identifier, but in fact it has other options.

Cookie Mechanism. The orthodox cookie distribution is implemented by extending the HTTP protocol. The server prompts the browser to generate the corresponding cookie by adding a special line in the HTTP response header. However, pure client scripts such as JavaScript or VBScript can also generate cookies. Cookies are automatically sent to the server in the background by the browser according to certain principles. The browser checks all stored cookies. If the declared range of a cookie is greater than or equal to the location where the requested resource is located, the cookie is attached to the HTTP request header of the requested resource and sent to the server.

How to store Cookies

Cookies are stored on your local machine. Different browsers are stored in different folders and saved by domain name. That is, Cookies between websites are not covered by each other.

Users of IE can find the txt files of Cookies in local documents. windows server 2003/xp stores the files in different operating systems:

C: Documents and SettingsAdministratorCookies folder.

The name txt is saved by domain name. For example, the cookies in the localhost domain are:

Administrator@localhost1_12.16.txt or administrator@localhost1_22.16.txt

The [1] and [2] following change with each save.

3. How to transmit Cookies
Cookies are transmitted between the Web server and the browser. Save it in the Http request.

(1) Request page
When you request the Http header of a page, the local Cookies that belong to the page are added to the Http header. Note the following bold Section:

GET/Cookies/Test. aspx HTTP/1.1
Host: localhost: 1335
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; zh-CN; rv: 1.9.1.1) Gecko/20090715 Firefox/3.5.1 GTB5 (. net clr 3.5.30729)
Accept: text/html, application/xhtml + xml, application/xml; q = 0.9, */*; q = 0.8
Accept-Language: zh-cn, zh; q = 0.5
Accept-Encoding: gzip, deflate
Accept-Charset: GB2312, UTF-8; q = 0.7, *; q = 0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: My. Common. TestCookieInfo = Pkid = 999 & TestValue = aaabbbcccdddeee (2) page response
If the page requires writing Cookies, the returned Http is as follows. Note the bold Section:

HTTP/1.x 200 OK
Server: ASP. NET Development Server/9.0.0.0
Date: Thu, 06 Aug 2009 03:40:59 GMT
X-AspNet-Version: 2.0.50727
Set-Cookie: My. Common. TestCookieInfo = Pkid = 999 & TestValue = aaabbbcccdddeee; expires = Fri, 07-Aug-2009 03:40:59 GMT; path =/
Cache-Control: private
Content-Type: text/html; charset = UTF-8
Content-Length: 558
Connection: Close 4. How to view Cookies
(1) view txt files of Cookies
IE users can directly view the txt files of Cookies.
For example, C: Documents and settingsadministratorcookiesadministrator@localhost=12.16.txt

Session Mechanism

What is Session? Simply put, it is the number that the server sends to the client. When a WWW server is running, several users may browse the website running on this server. When a user establishes a connection with the WWW server for the first time, the user establishes a Session with the server, and the server automatically assigns a SessionID to the user to identify the unique identity. This SessionID is a random string consisting of 24 characters on the WWW server. We will see it in the following experiment.

This unique SessionID has great practical significance. When a user submits a form, the browser automatically attaches the user's SessionID to the HTTP header information (this is an automatic function of the browser and the user will not notice it ), after the server processes the form, it returns the result to the user corresponding to the SessionID. Imagine how the server knows which user submitted the form when two users register simultaneously without SessionID. Of course, SessionID has many other functions, which we will mention later.

In addition to SessionID, each Session contains many other information. However, for ASP or ASP. NET Programming and programming, the most useful thing is to access ASP/ASP. NET's built-in Session object to store their own information for each user. For example, if we want to know how many pages a user visits our website browses, we may add the following to each page that a user may access:

The Code is as follows:	Copy code
<% If Session ("PageViewed") = "" Then Session ("PageViewed") = 1 Else Session ("PageViewed") = Session ("PageViewed") + 1 End If %>

You can use the following sentence to learn about several pages you have browsed:

 

The Code is as follows:	Copy code
<% Response. Write ("You have viewed" & Session ("PageViewed") & "pages ") %>

Some readers may ask: where does this seemingly array Session ("...") come from? Do I need to define it? In fact, this Session object is a built-in object of the WWW server with ASP interpretation capability. That is to say, this object has been defined for you in the ASP system, and you only need to use it. The variable name in Session ("...") is like the variable name. The $ in Session ("...") =$ $ is the variable value. You only need to write a sentence to access the value in the variable .. on every page of the user.

In fact, ASP has a total of seven built-in objects, including Session, Application, Cookie, Response, Request, Server, etc. Similar objects are also available in other server-side scripting languages such as JSP and PHP, but they are not the same in terms of naming or usage.

ASP Session functional defects
Currently, ASP developers are using Session, but they have discovered the following defects in ASP Session:

Process dependency: the ASP sessionstate is stored in the iisprogress, And the inetinfo.exe program is also used. When the inetinfo.exe process crashes, the information is lost. In addition, restarting or disabling the IIS service will cause information loss.
Limitations of the range of Session Status usage: when a user accesses another website from one website, the Session information will not be migrated. For example, there may be more than one WWW server on the Sina website. After a user logs on, he/she will go to various channels, but each channel is on a different server, what if I want to share Session information on these WWW servers?
Cookie dependency: in fact, the client's Session information is stored in the Cookie. If the client completely disables the Cookie function, it cannot enjoy the function provided by the Session.
In view of the above defects of ASP Session, Microsoft designers are designing and developing ASP. NET Session, and the above defects are completely overcome, making ASP. NET Session has become a more powerful feature.

Session configuration information in the Web. config file
After opening the configuration file Web. config of an application, we will find the following section:

The Code is as follows:	Copy code
<SessionState Mode = "InProc" StateConnectionString = "tcpip = 127.0.0.1: 42424" SqlConnectionString = "data source = 127.0.0.1; Trusted_Connection = yes" Cookieless = "false" Timeout = "20" />

This section describes how the application stores Session information. The following operations mainly aim at this configuration section. Let's take a look at the meaning of the content contained in this section. The syntax of the sessionState node is as follows:

The Code is as follows:	Copy code
<SessionState mode = "Off | InProc | StateServer | SQLServer" Cookieless = "true | false" Timeout = "number of minutes" StateConnectionString = "tcpip = server: port" SqlConnectionString = "SQL connection string" StateNetworkTimeout = "number of seconds" />

A frequently used technology called URL rewriting is to directly append the session id to the end of the URL path. Another technique is form hidden fields. The server automatically modifies the form and adds a hidden field so that the session id can be passed back to the server when the form is submitted. For example:

The Code is as follows:	Copy code
<Form name = "testform" action = "/xxx"> <Input type = "hidden" name = "jsessionid" value = "ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng! -145788764 "> <Input type = "text"> </Form>

In fact, this technology can be simply replaced by rewriting the URL of the action application.