httpsession原理

TTP协议（http://www.w3.org/Protocols/）是“一次性单向”协议。 
服务端不能主动连接客户端，只能被动等待并答复客户端请求。客户端连接服务端，发出一个HTTP Request，服务端处理请求，并且返回一个HTTP Response给客户端，本次HTTP Request-Response Cycle结束。 
我们看到，HTTP协议本身并不能支持服务端保存客户端的状态信息。于是，Web Server中引入了session的概念，用来保存客户端的状态信息。 
这里用一个形象的比喻来解释session的工作方式。假设Web Server是一个商场的存包处，HTTP Request是一个顾客，第一次来到存包处，管理员把顾客的物品存放在某一个柜子里面（这个柜子就相当于Session），然后把一个号码牌交给这个顾客，作为取包凭证（这个号码牌就是Session ID）。顾客（HTTP Request）下一次来的时候，就要把号码牌（Session ID）交给存包处（Web Server）的管理员。管理员根据号码牌（Session ID）找到相应的柜子（Session），根据顾客（HTTP Request）的请求，Web Server可以取出、更换、添加柜子（Session）中的物品，Web Server也可以让顾客（HTTP Request）的号码牌和号码牌对应的柜子（Session）失效。顾客（HTTP Request）的忘性很大，管理员在顾客回去的时候（HTTP Response）都要重新提醒顾客记住自己的号码牌（Session ID）。这样，顾客（HTTP Request）下次来的时候，就又带着号码牌回来了。 
我们可以看到，Session ID实际上是在客户端和服务端之间通过HTTP Request和HTTP Response传来传去的。 

我们看到，号码牌（Session ID）必须包含在HTTP Request里面。关于HTTP Request的具体格式，请参见HTTP协议（http://www.w3.org/Protocols/）。这里只做一个简单的介绍。 
在Java Web Server（即Servlet/JSP Server）中，Session ID用jsessionid表示（请参见Servlet规范）。 
HTTP Request一般由3部分组成： 
（1）Request Line 
这一行由HTTP Method（如GET或POST）、URL、和HTTP版本号组成。 
例如，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 
这部分定义了一些重要的头部信息，如，浏览器的种类，语言，类型。Request Headers中还可以包括Cookie的定义。例如： 
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.somesite/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服务、网上银行等系统）根据这些信息进行身份验证和权限验证

新客户端向服务器第一次发送请求的时候，request中并无sessionID .
2 此时server端会创建一个session对象，并分配一个sessionID，serssion对象会保存在服务器端。此时session的状态处于new state状态，如果调用session.isNew(),则返回true
3 当服务器段处理完毕后，将此sessionID，同response一同传回到客户段，并将其存入到cookie中。
4 当客户段再次发送请求时，会将sessionID 同request一起发送，传递给服务器端。
5 服务器端可以根据传递过来的sessionID将这次请求（request）与保存在服务器端的session对象联系起来，此时的session已不处于new state状态，如果调用session.isNew(),则返回false.
6 循环3-5 ，直到session超时或销毁。

ServletContext接口- -
                                      

安装在一个服务器中的一个特定URL名字空间（比如，/myapplication）下的所有Servlet，JSP，JavaBean等Web部件的集合构成了一个Web的应用，每一个Web应用（同一JVM），容器都会有一个背景对象，而javax.servlet.ServletContext接口就提供了访问这个背景对象的途径。
你可以通过一个Servlet实例的getServletContext方法得到该Servlet运行其中的这个背景对象。从这个背景对象中你可以访问如下信息或资源：
    
日志

可以调用ServletContext.getInitParameterNames()返回一个初始化参数的枚举对象（java.util.Enumeration），或直接指定一个参数名来得到特定的参数值：ServletContext.getInitParameter(String name)。另外，在Servlet的背景中还可以存放与特定名字绑定的任意类型的对象，比如：
  context.setAttribute(String name, Object object);
将把object对象绑定到名字name，存放在Servlet背景中，可供同一背景中的其他Servlet共享。其他Servlet可以通过
context.getAttribute(String name)，得到一个背景中的对象，或通过context.removeAttribute(String name)在背景中移除一个对象。
  一个特定资源的URL可以通过调用ServletContext.getResource(String path)得到，这儿的path参数必须以“/”开始，将被解析为相对于当前Servlet背景的根的相对路径。这个方法有别于基于类加载器的java.lang.Class.getResource方法。如果你通过
  ServletContext.getResource方法请求了一个.jsp页面，你得到的将是JSP的源码，要得到执行结果，可以使用RequestDispatcher对象的include方法。
    关于Config参数和Context参数的访问
ServletConfig和ServletConfig参数访问

我们先来回顾一下各种内置对象的作用范围

HttpServletRequest,HttpServletResponse:这两个属性的作用范围最小。
时间上：只是本身请求和应答完成就失效，当然转发是把当前的request对象取出来传给另一
个资源，其实本身的request对象还是只生存到本次请求结束，response也同样。
空间上：只能发送请求的客户端有效。

HttpSession:一次连结到客户端关闭，时间作用范围比上面两个大，空间任用范围相同。

ServletConfig:从一个servlet被实例化后，对任何客户端在任何时候访问有效，但仅对本servlet
有效，一个servlet的ServletConfig对象不能被另一个servlet访问。

ServletContext:对任何servlet，任何人在任何时间都有效，这才是真正全局的对象。

那么，ServletConfig参数和ServletContext参数到底应该如何使用，如何取得？

一般来说，对整个应用的配置，为了不使用“硬编码”，应该配置为ServletContext参数，比如字
符集设定。
<web-app>
.................
<init-param>
<param-name>charset</param-name>
<param-value>GB2312</param-value>
</init-param>
.................
</web-app>
注意以上格式只是2。0以后的标准格式，旧容器（引擎）采用服务商自己的格式配置。注意它的
父元素应该是<web-app>也就是说它是对一个应用作用的。

而如果只有一个特定的servlet要设定的参数，其它servlet不能共享，应该配置为ServletConfig
参数，如一个读取附件的servlet要用到绝对目录，而别的servlet不会用到：
<servlet>
<servlet-name>GetAtt</servlet-name>
<servlet-class>mail.GetAttServlet</servlet-class>
<init-param>
<param-name>absPath</param-name>
<param-value>/usr/mail/ax/axman/Maildir/</param-value>
</init-param>
</servlet>
不用说，因为在<servlet>标签中已经指定了name和class,也就是说只有mail.GetAttServlet这个\r
servlet中才能取到path,而别的Servlet是不能取到的。

那么如何访问这两个对象的参数呢？
访问ServletConfig参数：
首先要取得ServletConfig对象，然后调用它的getInitParameter();方法。要访问
ServletConfig对象，jsp中直接使用config内置对象，但因为你的JSP编译后的servlet一般不会被
加到web.xml中的，所以一般不会通过jsp来取对本JSP编译后的servlet的配置参数，那么在servlet
中要得到ServletConfig对象有两种方法：

在inii()方法中取到：通过init的重载方法传递

.....
public class Test extends HttpServlet
{
ServletConfig config;
public void init(ServletConfig config) throws ServletException {
this.config = config;
}
..................
}
然后在下面的方法中就可以访问config对象。但要注意，为了确保能从构造方法中到到当前servlet的
config对象，应该调用父类的构造方法：
.....
public class Test extends HttpServlet
{
ServletConfig config;
public void init(ServletConfig config) throws ServletException {
super.init(config);
this.config = config;
}
..................
}

通过getServletConfig()方法直接到时，这样做的好处是不必调手工传递属性，想在任何时候都可
以得到。

还有第三种方法，要自己实现一些接口，这里作为一般讨论就不介绍了。

要访问ServletContext对象，只要从现有的ServletConfig对象getServletContext（）就可以了，然后\r
调用它的getInitParameter()方法就可以获取它的参数。

按说：ServletContext对象的作用域比ServletConfig作用域大，为什么要从ServletConfig中到得
ServletContext对象呢？我个人认为：容器保存了很多个ServletContext对象，请求时容器到底取哪一个\r
给你呢？那就取其中包含ServletConfig信息的那个给你，就是说取ServletConfig对象的父级对象。就好
象HttpSession要从requset中取得一样，就是取那个包含当前requese对象的session对象给你，这只是我
的个人想法，还没有来得及看具体