HTTP sessions (session)

A session is a persistent network protocol that creates an association between the user (or user agent) and the server side, and thus acts as a mechanism for exchanging packets

First, view Session ID

Use tools such as Firebug,httpwatch to view session IDs

The following is the HTTP request header information for accessing a site page (recorded as page 1)

As you can see, the session ID for access page 1 o'clock is abcmipguzcztqannnluhu

The following is the HTTP request header information for a page that accesses another site (recorded as page 2)

As you can see, the session ID of the access page 2 o'clock is: b035123e4066ec2b270c5fc07260b08f

Description

1. The session ID can be found through the conversation token in the cookie: Session name=session ID, which, in which sessions name, which is called Jssessionid (JSP, WebLogic ), Phpsessid (PHP), can be customized by function

2. session name, can contain only subtitles, numbers, and at least one letter

3. accessing pages from different sites, generating session IDs that are not the same

Second, the session mechanism

A session mechanism is a server-side mechanism by which a server makes a data structure (possibly a hash table) to hold information

The session process is as follows:

1. Client-----Send Request-----> server

2, the server check whether the request contains session ID, according to different circumstances to take different actions

In two different cases

A) scenario one: The request contains a session ID

Retrieves the corresponding session information based on session ID, if it is not retrieved (the session information is deleted due to timeout), creates a file or a data structure variable to hold the session information, and generates the session ID associated with the file or data structure variable

Note: The request contains session ID, indicating that the server has saved the conversation information for the client;

b) scenario Two: The request does not include the session ID

Create a file or a data structure variable that holds the session information and generate a file or data structure variable off

The session ID of the joint

3, the session ID in response to the message sent to the client, if the client's request does not include the session ID, then the server will also give instructions to instruct the client to save the session ID, such as the first time the client initiates a request to the server, you can see that The request headers received by the client contain Set-cookie

Note: As can be seen from the diagram, the cookie is issued by the server

4. When the client again initiates access to another or the same page request, the session ID saved in the cookie is automatically sent in the request. For example, the request header that is sent when the request is sent again (note: If the session ID is present and is still valid, such as if the browser is not closed)

Description

1. The client is usually a browser

2.session ID Unique, a session ID represents a conversation

Test (under IE8)

Step 1, disable browser cookies

Step 2, re-visit a website to view cookies, view the request header

Result: Disable browser Cookie, can see the status of the cookie is received, received the request header information has been Set-cookie

Step 3, enable browser cookies, repeat two times to visit the site after viewing cookies

Result: Cookies are turned on, the second time you visit the website, the status of the cookie is sent

URL rewrite

Since cookies can be artificially banned, there must be other mechanisms to ensure that the session ID is still passed back to the server when the cookie is banned. A technique that is often used is called URL rewriting: attaches the session ID directly behind the URL path: One is additional information as a URL path, in the form of:

Http://...../xxx;jsessionid=ByOK ... 99zwpbng!-145788764

The other is appended as a query string behind the URL, in the form of: Http://...../xxx?jsessionid=ByOK ... 99zwpbng!-145788764

These two ways for the user is no difference, but the server in the resolution of the way the process is different, the first way is also conducive to the session ID information and normal program parameters separated.

In order to maintain state throughout the interaction, the session ID must be included after each client may request a path.

Third, session survival time

The following tests are performed first:

1. Delete local cookies, same browser, different tabs open the same site on the same page, see if the session ID changes

Result: The same session ID that you see when you visit a page in each tab

2. Delete local cookies, same browser, different tabs to open different pages of the same site, to see if the session ID changes

Result: same site, same session ID when accessing different pages

3. Delete local cookies, different browsers (the same type, such as IE), open the same site on the same page, view, see if the session ID changes

Result: Session ID remains unchanged when accessing the same page

4. record the current session ID, delete the cookie, close the label page, and reopen the same page on the same site to see if the session ID changes

Result: The session ID remains the same without closing the browser

5. record the current session ID, close all browsers, open the same page again on the same site to see if the session ID changes

Result: The session ID changed

6. in different types of browsers, open the same page of the same site to see if the session ID changes

Result: The session ID changed

7. visit the same Web page again the next day to see if the session ID changes

Result: The session ID changed

You can conclude that:

1. in general, the session lifetime is:

Start: Client (usually browser)-sends the first request-to-server and successfully establishes a connection with each other

End: Closes the client (usually the browser) or the session times out

2. Different sessions are generated when a page is accessed by a different browser on the same site

3. here the cookie, stored in the browser memory is not written to the hard disk, we call the session Cookie,session cookie for a session, the session ends, and the sessions cookie disappears

Attention:

1. the "usual" reason is that a client sending a page request does not necessarily create a session, and the session is actually created when a statement like Httpservletrequest.getsession (true) is called by the server-side program.

2. accessing the local xx.html page without creating a session

About "Session Timeout"

In the HTTP protocol, the client is no longer active without a clear termination signal. Therefore, a timeout is used to identify inactive clients within a specified time, which automatically ends the session when inactive time exceeds the specified time, which helps to conserve resources. For example, when you log in to a website, but there are things that leave the computer, long time does not do web browsing and other interactions with the server, when you come back, click on a hyperlink, it automatically prompts you to sign in again. This is a typical example.

Iv. Session Information Lifetime

1. when the last time the session information is used by the client exceeds the specified "timeout" time, the server considers that the client has stopped the activity and automatically deletes the saved session information

2. when the server program calls Httpsession.invalidate (), delete the session information

3. server shutdown or service stop (for non-persistent sessions), session information is deleted

Note: Unless the client notifies the server to delete session variables, the server is not actively removed. Generally, when the user does log off to send a command to delete the session information, the browser will never proactively notify the server before shutting down it will shut down, so the server does not have the opportunity to know that the browser is closed, so most of the session mechanism uses session Cookie to save the session ID, and the session ID disappears when the browser is closed, and the original conversation information cannot be found when the server is connected again. Therefore, the server sets an expiration time for each session and deletes the session information to save storage space when the session information was last used by the client longer than the expiration time.

However, if the cookie set by the server is saved to the hard disk, or if a device is used to overwrite the HTTP request header sent by the browser, and the original session ID is sent to the server, the original session can still be found by opening the browser again.

Test validation:

Access a Web site, get the request header, method, Request page (available firebug)

Close the browser, then reopen, manually edit the request, send the request, and discover that it is actually available.

v. Sessions and Cookies

Using a classical analogy on the network

A coffee shop for customers to launch promotional activities: Buy 5 cups of coffee in a row, you can give a cup, and usually consumers do not buy 5 cups at a time, so no matter how many times, the store must know each customer's consumption, to determine whether to meet the gift conditions

There are two more feasible ways to handle this:

1, to each customer a card, which records the amount of customer consumption (there is usually a valid period), each time consumption, if the customer presented this card, then the consumption will be associated with the previous or subsequent consumption-this practice is to stay in the client state.

2, to each customer a membership card, in addition to the card number of what information is not recorded, each time the consumer, if the customer presented the card, then the shop clerk in the record of the store to find this card number corresponding record add some consumer information-this practice is to maintain state on the server side.

Because the HTTP protocol is stateless, each time the browser accesses a different Web page, the server opens a new session, and the server does not automatically maintain the client's contextual information (that is, the value of the variables stored on this page will not be taken to the next page) , The client simply needs to request resources from the server, whether the client or the server does not record each other's past behavior, each request is independent, take the coffee point of the example, that is, customers do not remember when the coffee shop, how many cups of coffee purchased, The store also doesn't remember whether customers have been to their own stores, whether they have bought them, or how many cups of coffee they have bought.

However, we sometimes need to have a state, such as the above example of the coffee shop, such as the shopping cart mechanism, on a certain page to put an item into the shopping cart, when the access to other pages, still visible in the shopping cart items, which requires a session to save the context information mechanism, Session is for each user, through the session ID to distinguish between different users

Taking the above example,

A cookie is a scheme that maintains state on the client side, and the session uses a state-of-the-server scenario, and from the coffee shop example, it is better to keep it on the server side. At the same time, we also see that due to the server-side retention scheme in the client also need to save an identity (session ID), so the session may need to use cookies to achieve the purpose of preserving the identity, it is possible because there are other ways, such as URL rewriting

HTTP sessions (session)