The HTTP protocol ( http://www.w3.org/Protocols/ ) is a "one-time one-way" protocol.
The server cannot actively connect to the client, but can only passively wait and reply to the client's request. The client connects to the server, sends an HTTP Request, the server processes the 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 server to save the client's state information. Therefore, the concept of session is introduced in Web Server to save the state information of the client.
Here is an image metaphor to explain how the session works. Suppose the Web Server is a store in a shopping mall, and the HTTP Request is a customer. The first time he came to the store, the administrator stored the customer's items in a certain cabinet (this cabinet is equivalent to a session), and then put a The number plate is handed over to the customer as a voucher for picking up the package (this number plate is the Session ID). When the customer (HTTP Request) comes next time, the number plate (Session ID) must be handed over to the administrator of the storage office (Web Server). The administrator finds the corresponding cabinet (Session) according to the number plate (Session ID), and according to the request of the customer (HTTP Request), the Web Server can take out, replace, and add items in the cabinet (Session). Request) number plate and the cabinet (Session) corresponding to the number plate are invalid. The customer (HTTP Request) is very forgetful, and the administrator has to remind the customer to remember their number plate (Session ID) again when the customer goes back (HTTP Response). In this way, the next time the customer (HTTP Request) comes, he will come back with the number plate.
We can see that the Session ID is actually passed back and forth between the client and the server through HTTP Request and HTTP Response.
We see that the number plate (Session ID) must be included in the HTTP Request. For the specific format of HTTP Request, see HTTP Protocol (http://www.w3.org/Protocols/). Here is just a brief introduction.
In Java Web Server (ie Servlet/JSP Server), Session ID is represented by jsessionid (see Servlet Specification).
HTTP Request generally consists of 3 parts:
(1) Request Line
This line consists of HTTP Method (such as GET or POST), URL, and HTTP version number.
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
This part defines some important header information, such as browser type, language, type. Request headers can also include a cookie definition. 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
如果HTTP Method是GET，那么Message Body为空。
如果HTTP Method是POST，说明这个HTTP Request是submit一个HTML Form的结果，
那么Message Body为HTML Form里面定义的Input属性。例如，
user=guest
password=guest
jsessionid=1001
主意，如果把HTML Form元素的Method属性改为GET。那么，Message Body为空，所有的Input属性都会加在URL的后面。你在浏览器的URL地址栏中会看到这些属性，类似于
http://www.fastfish/login.do?user=guest&password=guest&jsessionid=1001
从理论上来说，这3个部分（Request URL，Cookie Header, Message Body）都可以用来存放Session ID。由于Message Body方法必须需要一个包含Session ID的HTML Form，所以这种方法不通用。
一般用来实现Session的方法有两种：
（1）URL重写。
Web Server在返回Response的时候，检查页面中所有的URL，包括所有的连接，和HTML Form的Action属性，在这些URL后面加上“;jsessionid=XXX”。
下一次，用户访问这个页面中的URL。jsessionid就会传回到Web Server。
（2）Cookie。
如果客户端支持Cookie，Web Server在返回Response的时候，在Response的Header部分，加入一个“set-cookie: jsessionid=XXXX”header属性，把jsessionid放在Cookie里传到客户端。
客户端会把Cookie存放在本地文件里，下一次访问Web Server的时候，再把Cookie的信息放到HTTP Request的“Cookie”header属性里面，这样jsessionid就随着HTTP Request返回给Web Server。
我们来看Tomcat5的源代码如何支持jsessionid。
org.apache.coyote.tomcat5.CoyoteResponse类的toEncoded()方法支持URL重写。
String toEncoded(String url, String sessionId) {
…
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());
}
我们来看org.apache.coyote.tomcat5.CoyoteRequest的两个方法configureSessionCookie()
doGetSession()用Cookie支持jsessionid.
/**
* Configures the given JSESSIONID cookie.
*
* @param cookie The JSESSIONID cookie to be configured
*/
protected void configureSessionCookie(Cookie cookie) {
…
}
HttpSession doGetSession(boolean create){
…
// Creating a new session cookie based on that session
if ((session != null) && (getContext() != null)
&& getContext().getCookies()) {
Cookie cookie = new Cookie(Globals.SESSION_COOKIE_NAME,
session.getId());
configureSessionCookie(cookie);
((HttpServletResponse) response).addCookie(cookie);
}
…
}
Session的典型应用是存放用户的Login信息，如用户名，密码，权限角色等信息，应用程序（如Email服务、网上银行等系统）根据这些信息进行身份验证和权限验证
1：Session对象在浏览器中的有效范围：
IE中:
1〉.Session对象只在建立Session对象的窗口中有效。
2〉.在建立Session对象的窗口中新开链接的窗口也有效。
Session只会在内存中，他会随着IE窗口的关闭而死亡。
也就是说单用seesion是不会有产生自动登入的效果的。
2：Cookie 是在服务器给客户端IE一个命令后在客户端产生并存的，
它可以存放用户信息，存到客户端硬盘上，在COOKIE记录被删除
或者失效日期之前，就可以实现自动登入的现象。
3：Session 和 Cookie 是不同的，但是他们确实是相关的。
当打开IE登入后，会向服务器发出一个指令请求SESSIONID以
及页面内容，服务器会返回页面内容和一个没有被使用的
SESSIONID让此IE使用，当时IE就对返回SESSIONID做存储；而当此IE再访问任何这个站点的JSP程序的时候,都会给服务器这个 SESSIONID，来确认客户端的身份。（在没有Cookie 的情况下session死亡 SESSIONID被取消就需要重新登入）
4：可以通过客户端禁用和不禁用cookie来验证自己的说法。