HTTP session 1. Analysis of the HTTP protocol (http://www.w3.org/protocols/) is a "one-way single-direction" protocol. The server cannot actively connect the client, which can only be paid and respond to the client request. The client connection server, issues an HTTP Request, the server processing request, and returns an HTTP response to the client, this http request-response cycle ends. We see that the HTTP protocol itself does not support the status information of the client to save the client. Thus, the concept of session is introduced into the web server to save the status information of the client. Here is a metaphor of an image to explain the Way of SESSION. Suppose Web Server is a mall's stock package. HTTP Request is a customer. The first time I came to the package, the administrator stored the customer's item inside a piece of cabinet (this cabinet is equivalent to session), then one The number card is handed over to this customer, as a package certificate (this number is the session ID). When the HTTP Request is next, the session ID will be administered to the administrator of the Sakura (Web Server). The administrator finds the corresponding cabinet according to the number card (SESSION ID), according to the customer (HTTP Request) request, Web Server can replace, replace, add the items in the session, Web Server can also make customers (http Request's number card and number card corresponding to the cabinet failure. The HTTP Request is very forgotten, and the administrator will re-remind customers to remember their number card (HTTP RESPONSE). In this way, when the customer (HTTP Request) came back next time, he came back again. The Session ID is actually transmitted between the client and the server via HTTP Request and HTTP Resonse. The number card (session ID) must be included in the HTTP REQUEST. For the specific format of HTTP Request, see the HTTP protocol (http://www.w3.org/Protocols/). I only make a simple introduction here. In Java Web Server (ie, servlet / jsp server), the session ID is represented by jsessionID (see the servlet specification). HTTP Request is generally consisting of 3 parts: (1) Request Line This line consists of HTTP Method, URL, and HTTP version numbers.
For example, get http://www.w3.org/pub/www/theproject.html http / 1.1 get http://www.google.com/search?q=tomcat http / 1.1 post http://www.google .com / search http / 1.1 get http://www.somsite.com/menu.do ;jsessionID=1001 HTTP / 1.1 (2) Request Headers defines some important headers, such as the type of browser , Language, type. The Request Headers can also include the definition of cookies. For example: User-agent: mozilla / 4.0 (compatible; msie 5.5; Windows NT 5.0) Accept-language: en-us cookie: jsessionID = 1001
(3) Message Body If the http method is get, the Message Body is empty. If http method is POST, this HTTP Request is the result of the Submit an HTML Form, then the message body is the INPUT property defined in the HTML Form. For example, user = guest password = guest jsessionID = 1001 idea, if the Method property of the HTML FORM element is changed to get. Then, Message Body is empty, and all INPUT properties will be added behind in the URL. You will see these properties in the URL address bar of your browser, similar to http://www.somesite/login.do? User = guest & password = guest & jsessionID = 1001
In theory, these three parts (Request URL, Cookie Header, Message Body) can be used to store session IDs. Since the Message Body method must require an HTML Form containing the session ID, this method is not universal. There are two ways to implement session: (1) URL rewriting. When returning Response, Web Server checks all URLs in the page, including all connections, and HTML Form's action properties, add "; jsessionID = xxx" behind these URLs. Next time, the user accesses the URL in this page. JSessionID will pass back to Web Server. (2) cookie. If the client supports cookie, Web Server is returned to Response, add a "set-cookie: jsessionid = xxxx" header property in response, put the jsessionID to the client in cookie. The client stores the cookie in the local file. When the next time I accessed the web server, put the cookie's information in the "cookie" header property of the HTTP Request, so jsessionID will return to Web Server as the HTTP Request is returned to Web Server. Second, the relevant information is a personal opinion of my self-satisfaction, let me find some authoritative information support. http://www.w3.org/protocols/
Use of users
HTTP
State
Management (RFC 2964).
ftp://ftp.rfc-editor.org/in-notes/rfc2964.txt
This file is the "HTTP State Management" extension protocol section. There is such a paragraph in it.
IT's important to realize what similar capabilities may also be achieved using the "bare" http protocol, and / or dynamically-generated
. HTML, without the State Management extensions For example, state information can be transmitted from the service to the user by embedding a session identifier in one or more URLs which appear in HTTP redirects, or dynamically generated HTML; and the state information may be returned From the user to the service. html forms can also be used to pass state information from the service to the user and back, the user being aware of this happens.
The meaning of this paragraph is, do not need this "HTTP State Management" extended protocol part, we can also implement session with "pure" HTTP protocol - such as URL rewrite, HTML Form, etc.
There is no cookie mentioned here. Because the "HTTP State Management" extension protocol part itself includes content about cookie. This can pass
HTTP
State
Management Mechanism (RFC 2965),
ftp://ftp.rfc-editor.org/in-notes/rfc2965.txt
figure it out.
State and sessions
This document describes a way to create stateful sessions with HTTP requests and responses Currently, HTTP servers respond to each client request without relating that request to previous or subsequent requests;. The state management mechanism allows clients and servers that wish to exchange state information to place HTTP requests and responses within a larger context, which we term a "session". This context might be used to create, for example, a "shopping cart", in which user selections can be aggregated before purchase, or a magazine browsing system, in which a user's previous reading affects which offerings are presented.Neither clients nor servers are required to support cookies. A server MAY refuse to provide content to a client that does not return the cookies it sends.
Also give an example (the Chinese part is me added).
4.1 EXAMPLE 1
Most Detail of Request and Response Headers Has Been OMIMITTED. Assumeme
The User Agent Has No Stored Cookies.
User agent -> Server
Post / ACME / LOGIN HTTP / 1.1
[Form Data]
User Identifies Self Via A Form.
2. Server -> User Agent
HTTP / 1.1 200 ok
Set-cookie2: Customer = "wile_e_coyote"; version = "1"; path = "/ acme"
Cookie Reflectes User's Identity.
(Customer = "wile_e_coyote" this should be in Form Data, this time is passed back to the client)
3. User Agent -> Server
Post / ACME / PICKITEM HTTP / 1.1
Cookie: $ version = "1"; customer = "wile_e_coyote"; $ PATH = "/ acme"
[Form Data]
User selects an item for "shopping basket".
4. Server -> User Agent
HTTP / 1.1 200 ok
Set-cookie2: part_number = "Rocket_Launcher_0001"; Version = "1";
Path = "/ acme" Shopping Basket Contains An Item.
(This rocket transmitter is obviously from Form Data. But why is part_number = "Rocket_Launcher_0001" also needs to pass back to the client?
Customer = "wile_e_coyote"; should be sent back to the client in the traditional "set-cookie". The role of "set-cookie2" should be added to cookies. )
5. USER Agent -> Server
Post / ACME / SHIPPING HTTP / 1.1
Cookie: $ VERSION = "1";
Customer = "wile_e_coyote"; $ PATH = "/ acme";
Part_number = "Rocket_Launcher_0001"; $ PATH = "/ ACME"
[Form Data]
User Selects Shipping Method from Form.
(Customer passed to the server, including Customer and Part_Number)
6. Server -> User Agent
HTTP / 1.1 200 ok
Set-cookie2: shipping = "fedex"; version = "1"; Path = "/ acme"
New cookie reflectes shipping method.
7. USER Agent -> Server
Post / ACME / Process HTTP / 1.1
Cookie: $ VERSION = "1";
Customer = "wile_e_coyote"; $ PATH = "/ acme";
Part_number = "Rocket_Launcher_0001"; $ PATH = "/ acme";
Shipping = "fedex"; $ PATH = "/ acme"
[Form Data]
User chooses to process.
8. Server -> User Agent
HTTP / 1.1 200 ok
Transaction is Complete.
The user agent makes a series of requests on the origin server, after each of which it receives a new cookie. All the cookies have the same Path attribute and (default) domain. Because the request-URIs all path-match / acme, the Path Attribute Of Each Cookie, Each Request Contains All The Cookies Received So Far.
(Seeing this, I will understand that the $ PATH = "/ acme" roughly played the role of JSessionID)
Third, Tomcat5's HTTP session implementation Here we look at Tomcat5 source code how to support http 1.1 session. We can search for Tomcat5 source code with keywords such as jsessionid, set-cookie.
First, let's define constants: org.apache.catalina.Globals / ** * The name of the cookie used to pass the session identifier back * and forth with the client * / public static final String SESSION_COOKIE_NAME = "JSESSIONID";.
/ ** * The name of the path parameter used to pass the session Identifier * Back and forth with the client. * / Public static firm string session_parameter_name = "jsessionID";
Cookies Inside the uppercase JSessionID, the URL suffix is lower-written JSessionID. The specific implementation class of session is org.apache.catalina.session.standardSession. All sessions of a Tomcat Server are managed by a Manager (with a context). I estimate that there is a session listener to manage the session data replication between Cluster, and I have not traced it.
Several important related classes are three classes of CoyoteRequest, CoyoteResponse, CoyoteAdapter below the org.apache.coyote.tomcat5 pack.
Org.apache.coyote.tomcat5.coyoteResponse class toEncoded () method supports URL rewrite. String toEncoded (String Url, String Session) {... stringbuffer sb = new stringbuffer (path); if (sb.Length ()> 0) {// jsessionid can't be first. Sb.append ("; jsessionID =") Sb.append (sessionid);} sb.append (anchor); sb.append (query); return (sb.toString ());}
Let's look at the two methods of org.apache.coyote.tomcat5.coyoteRequest Configuration ConfigurationID () supports JSessionID with cookies.
/ ** * configures the given jsessionid cookie. * * @Param cookie the jsessionid cookie to be configured * / protected void configuressioncookie (cookie cookie) {...}
HttpSession DogetSession (Boolean Create) {... // Creating A New Session Cookie Based On That Session IF (GetContext ()! = Null && getContext (). GetCookies ()) {cookie cookie = new Cookie (globals.Session_cookie_name, session.get ()); (httpservletresponse); (httpservletResponse); (httpservletResponse); ((HTTPSERVLETRESPONSE); ((HTTPSERVLETRESPONSE) response) .addcookie (cookie);} ...} four, more http session protocol, specification, and implementation. In addition, the use of session in Frameset is somewhat complicated, and different environmental performance may be different. The remaining related concepts have "Sing Sign On - SSO), Domain, Cluster, Proxy, Cache, etc.
