Session state hold, Jsessionid,cookie,url rewrite

Incredibly have 3W of traffic, good, I put the session and cookie relationship first to a summary, attention, is the most simple and straightforward summary.

HTTP protocol, Protocol, protocol, important say 3 times, HTTP protocol mainly has 2 large chunks, the request header and the request body, the cookie in the HTTP request head, is a multiple kv composition string, among them has a key=jsessionid.

The client---The 1st time--->sever,header cookie without Jssionid

Server--response--->client, the server found no Jssionid in the request header, OK, I'll give you a random value, return to you, in response header, one more thing, Set-cookie: Jsessionid=xxx

Client--reveive response from server, I found Set-cookie in the response header, so I'll take these cookies with me when I request the server later, which includes the Jsessionid

Client--the 2nd time--->server, with all the cookie content

The server---response--->client with all the cookie content

Therefore, session-based conversation is maintained by the client and the server to work together to complete, server generated SessionID, and then everyone has been passed, and so has been playing until session timeout, or cancellation.

Today talk about the relationship between the Jsessionid,cookie and the state of conversation

On the server side, we used a line of code such as Session.setattribute ("", UserInfo), and it is estimated that you rarely think of how the server and the browser maintain session state. Well, first quote some of the highlights of the article:

Http://www.xxx.com/xxx_app;jsessionid=xxxxxxxxxx?a=x&b=x.

This is basically the same as the general URL, only one place has a difference, that is "; Jessionid=xxxxxxxx". This parameter sometimes has, sometimes does not, said it is the parameter may differ from the general passing parameter, it is immediately after the URL separated by the semicolon, uses the general Request.getparameter () method also to take the Jsessionid.

Start your tomcat, turn on Firefox (Love very much, be sure to install firebug), input localhost on the line, open Firebug, point Network, you will see, browser and server session information, give the browser

(1) Request the server for the first time:

Request header information for the browser

Host	localhost
User-agent	mozilla/5.0 (Windows; U Windows NT 5.1; ZH-CN; rv:1.9.2.6) gecko/20100625 firefox/3.6.6
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	115
Connection	Keep-alive

In the following figure

In the following figure

Server Response header information

Server	apache-coyote/1.1
Set-cookie	JSESSIONID=64D21B4D69DFB3041B6375C1932BD6CB; path=/
Content-type	Text/html;charset=utf-8
Content-language	Zh-cn
Content-length	242
Date	Mon, June 02:35:29 GMT

(2) Second request server:

Request header information for the browser

Host	localhost
User-agent	mozilla/5.0 (Windows; U Windows NT 5.1; ZH-CN; rv:1.9.2.6) gecko/20100625 firefox/3.6.6
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	115
Connection	Keep-alive
Cookies	Jsessionid=64d21b4d69dfb3041b6375c1932bd6cb

Server Response header information

Server	apache-coyote/1.1
Content-type	Text/html;charset=utf-8
Content-language	Zh-cn
Content-length	242
Date	Mon, June 02:37:51 GMT

Repeat the third time, every four times ... The nth request server, the browser and the server's request header information are the same as the second request server.

(3) However, if you add the following line of code on the server side:

Log.info ("SessionId:" + request.getsession (). GetId ());

You will see that when you first request the server, you will default to have a new session is created, and within the effective time of the session, this output value will not change, otherwise, the server will re-create a session, naturally, SessionID is also different, The output of this piece of code will naturally be different.

(4) You must be aware of this: you are using a browser to communicate with the server:

There are some things that browsers help us do: When you first communicate with the server, the browser saves the value of the Set-cookie that the server returns (JSESSIONID=64D21B4D69DFB3041B6375C1932BD6CB), As long as you do not close the browser (closed, close the tab does not count), the browser from the second request to the server to start, always with this key value pair, sent to the server. The server will know that this is a request initiated by the same person (the same session).

(5) We pay more attention to: Request.setattribute ("Sysuser", userInfo) This sentence:

When you first request the server, this code will be based on the server generated by default session of the ID, and with Sysuser=userinfo This key value pair hook (of course, userinfo can be any object), ensure the only association, to detect whether the user login is the way to achieve.

I must declare that it has nothing to do with whether a user is logged on or not.

(6) Once again, if you are not using a browser, such as doing J2ME development, how to maintain the session.

(1) After you have finished writing this line of code: Httpconnection HC = (httpconnection) connector.open (Httpurl), add the following code: (Constant.sessionid is just a static variable )

Set SessionID before communicating with the server, maintaining a unique session if (Constant.sessionid!= null) {Hc.setrequestproperty ("Cookie"), AppContext.CurrentAppContext.sessionID); }

(2) A: Read data only to the server, do not write data to the service, B: First write data to the server, and then read data from the server

For both cases, as soon as you open Opendatainputstream () for the first time, you can add the following code (Constant.islogin is just a static variable Boolean):

Save the sessionId String cookie = Hc.getheaderfield ("Set-cookie") after each communication with the server; if (cookie!= null) {String jsessionid = cookie.substring (0,cookie.indexof (";")); if (Constant.sessionid!= null && ; ! Constant.sessionID.equals (Jsessionid) && constant.islogin) {log.info ("SessionID timeout, 'll get new SessionID, but You must login Again "); Set to not logged in state Constant.islogin = false; } Constant.sessionid = Jsessionid; }

This will allow you to maintain a session.

(7) Finally, about URL redirection

Quote: Sun helps us think about it, so it offers 2 ways to make things simple: Response.encodeurl () and Response.encoderedirecturl (). These 2 methods will determine whether the cookie is available, if disabled will resolve the Jsessionid in the URL and connect to the specified URL, if not found Jessionid will automatically help us generate one. As to why there are 2 methods. What is the difference between these 2 methods? Google, said the 2 methods are slightly different in determining whether to include jsessionid logic. You should call the Encoderedirecturl () method before calling Httpservletresponse.sendredirect, otherwise you may lose sesssion information. The use of these 2 methods is as follows: Response.sendredirect (Response.encodeurl ("/myapp/input.jsp"));. If the cookie is not disabled, the address we see in the browser's address bar is this:/myapp/input.jsp, if cookies are disabled, we will see:/myapp/input.jsp;jsessionid= 73e6b2470c91a433a6698c7681fd44f4. So, when we write Web applications, for insurance purposes, we should use these 2 methods on every jump URL in the program to ensure the availability of the session.

Original quote

(8) Fighting and Keep moving!!