第六章
6 Filtering
Fileter是servlet2.3新增的部分。这一章介绍Filter类和方法，以及在web工程中的配置。
6.1什么是Fileter
Filter是重复使用的，用于变换HTTP请求和响应以及头信息中的内容。Filter不能像servlet那样创建
response响应，但可以修改请求和响应的内容。
6.1.1例举一些Filter
验证Filter
登陆，审核Filter
图像处理Filter
数据压缩Filter
加密Filter
XSL/T Filter
MIME Filter
6.2 主要观念
开发者通过创建实现javax.servlet.Filter接口的类，并提供一个没有参数的构造函数来创建一个Filter。
在描述文件中Fileter用filter表示，调用方法用filter-mapping进行配置。
6.3 Filter生命周期
在web工程发布后，在请求使引擎访问一个web资源之前，引擎必须定位Filter列表；引擎必须确保为列
表中的每一个Filter建立了一个实例，并调用了他们的init(FilterConfig config)方法。在这过程中可以抛
出异常。
部署描述文件中定义的所有filter，仅会在引擎中产生一个实例。
引擎为filter提供了一个FilterConfig类，该类附有ServletContext和一个带有初始化参数的set。
当引擎接受一个请求时，引擎就会调用filter列表中第一个filter的doFilter方法，把ServletRequest，
ServletResponse和FilterChain作为参数传给它。
filter中doFilter方法典型的处理步骤是：
1）检查请求头信息
2）开发者创建一个实现了ServletRequest或HttpServletRequest的类，去包装request对象，以
便修改请求的头信息或体数据。
3）开发者创建一个实现了ServletReqponse或HttpServletResponse的类，去包装response对
象，以便修改请求的头信息或体数据。
4)filter可以调用链中的下一个实体，下一个实体是另一个filter，如果该filter是列表中最后的一
个，则它的下一个实体就是一个目标web资源。如果要调用下一个filter的doFilter方法，把
request，和response对象传给FilterChain对象的doFilter方法中就可以了。
Filter chain 的doFilter方法是由引擎提供的，引擎在该方法中会定位filter列表中的下一个filter，
调用它的doFilter方法，把传来的request和response对象传给它。
5）在调用chain.doFilter之后，filter可以检测响应的头信息
6）在这些过程中，filter可以抛出异常。当在调用doFilter过程中抛出UnavailableException异常
时，引擎重复尝试处理下面的filter chain的方法，如过时后还没请求到filter chain 就会关闭对
filter chain的请求。
当filter是列表中最后一个filter时，它的下一个实体是描述配置文件中filter后面的servlet或其它
资源。
在引擎删除一个Filter之前，引擎必须调用Filter的destroy方法，来释放资源。
6.3.1 包装Requests 和Responsees
过滤的中心观念是对request或response的包装，在这种模式下，开发者不仅可以改写存在的方法，还
可以创建自己的新方法，用于特殊的过滤任务，例如：开发者希望扩展response对象，希望有个更高层
次的输出流对象（writer）。
为了支持包装模式，引擎不许保证在整个过滤链中，传递的request和response对象都是同一个对象。
6.3.2 Filter的环境
Filter的初始参数可以在描述配置文件中用init-params元素来配置，在运行时中，用FilterConfig的
getInitParameter和getInitParamesterNames方法得到配置参数。
6.3.3 Filter在web工程中的配置
在部署描述文件中：
filter-name:filter名称
filter-class:filter类路径
init-params:用于初始化参数
如果开发者在部署描述中为一个filter类描述了两个定义，则引擎会创建这个filter类的两个实例。
下面是个配置的例子:
<filter>
<filter-name>Image Filter</filter-name>
<filter-class>com.acme.ImageServlet</fiflter-class>
</filter>
一旦filter在部署描述中定义，filter-mapping就可以被定义了，filter-mapping在web应用中是定义关联
filter的servlet和静态资源的。
如：
<filter-mapping>
<filter-name>Image Filter</filter-name>
<servlet-name>ImageServlet</servlet-name>
</filter-mapping>
Image Filter 的 Filter就和ImageServlet 的Servlet建立了关联。
Filter 可以和一群servlet和静态资源关联，用url-pattern。如：
<filter-mapping>
<filter-name>Loging Filter</filter-name>
<url-pattern>/*</url-pattern>
<filter-mapping>
引擎建立特殊请求URI的Filter链的顺序是:
1)url-pattern映射fiter-mapping的顺序和描述文件中定义的顺序是一样的。
2）servlet-name映射filter-mapping的顺序和描述文件中定义的顺序是一样的。
这种需求要求引擎在接受请求时：
.识别符合SRV.11.2规则的web资源。
.如果一些filter是servlet和有servlet-name的web资源匹配的，引擎就会创建一个和描述文件中
映射servlet-name的顺序一样的filter链。
.如果一些filter是rul-pattern关联的，引擎就会创建一个和描述文件中映射url-pattern的顺序一
样的efilter链。
一个高性能的web容器将会缓存filter链。
第七章 Sessions
超文本传输协议（HTTP）是无状态的协议。要建立一个有效的web应用，客户端之间的通信是需要
的。有很多会话跟踪的策略，
但是直接使用这些技术都很难使用。servlet规范中提供了一个简单的HttpSession接口，不需要开发者
关心会话跟踪的具体细节。
7.1 会话跟踪机制
下面描述了几种会话的跟踪机制
7.1.1 Cookies
HTTP cookies是最常用的会话跟踪机制，所有的servlet引擎都应该支持这种方法。
引擎发送一个cookie到客户端，客户端就会在以后的请求中把这个cookie返回给服务器。用户会话跟踪
的cookie的名字必须是JSESSIONID
7.1.2 SSL Sessions
在安全套接字层，加密技术用在了HTTPS协议，从一个客户端来的多个请求允许用一个含糊的标识，
servlet引擎就用这个数据定义一个Session。
7.1.3 URL重写
URL重写是最低性能的通用会话跟踪方法。当一个客户端不能接受cookie时，URL重写就会作为基本的
会话跟踪方法；URL重写包括一个附加的数据，一个session id，这样的URL会被引擎解析和一个session
相关联。一个session id是作为URL的一个被编码的参数传输的，这个参数名字必须是jsessionid.如下面
的例子：
http://www.myserver.com/catalog/index.html;jsessionid=1234
7.1.4 会话的完整性
一个web容器必须支持HTTP 会话。而当cookies方法不被支持时，通常使用URL重写方法。
7.2 创建一个会话
servlet设计者必须考虑到一个客户端不能加入session的情况。
7.3 会话范围
HttpSession对象只在应用程序级有效，通常用于session的cookie可以服务于不同的上下文，但一个
HttpSession实例只服务于一个会话。举个例子：如一个servlet A用RequestDispatcher去调用另一个web
应用中的另一个servlet B，用于A和B的会话一定是两个不同的会话。
7.4 Session属性的邦定
一个servlet可以通过一个name邦定一个对象到HttpSession实例中；只要获得包含同一个会话的请求对
象，任何邦定到会话中的对象在同一个ServletContext中对于其它的servlet都是可用的。
当把一个对象放入session或从session删除时可能要通知其它对象，这些信息能够被实现了
HttpSessionBindingListener接口的对象获得，这个接口定义了一下的一些方法。
valueBound
valueUnbound
valueBound方法在HttpSession接口调用getAttribute方法获得一个有效的对象之前调用。valueUnbound
方法在HttpSession接口调用getAttribute方法获得一个不再有效的对象后调用。
7.5 会话超时
在HTTP协议中，当客户端不再有效时，没有清楚的定义终止信号。这就意味着通常只能采用时间超时
来表明客户端不再有效。
默认的超时时间是servlet引擎定义的，通过HttpSession的getMaxInactiveInterval方法可以得到超时的
时间；开发者可用用setMaxInactiveInterval方法来设置超时的时间，以秒定义的。如果一个session的
超时时间被设置为-1，则这个session将永远有效。
7.6 最后访问时间
在当前的请求中用HttpSession接口的getLastAccessedTime可以获得最后一次访问session的时间。
7.7 重要session
7.7.1 线程问题
在一个可以配置的应用中，所有的请求都是一个会话的一部分，引擎一定能够取出通过setAttribute或
putValue放入HttpSession对象中的对象。注意以下的情况：
.引擎一定能够访问实现了Serializable接口的对象。
.引擎可以选择存储HttpSession对象中指定的对象，如EJB组件和事务。
.引擎能够监听到会话的变动。
如果放入session中的对象没有被Seializable或没有效，servlet可以抛出IllegalArgumentException；如果
引擎不支持Session存储对象的机制，引擎一定会抛出IllegalArgumentException。
这些限制意味着，在一个分布式引擎中，不会有额外的并发问题。
如果引擎为了service的品质持续化或迁移session，使用本地持续化的HttpSession或它的属性是不受限
制的，开发者要想确保放入session中的属性对象能够可用，最好对象实现Serializable接口。
在迁移一个session时引擎必须通知session中实现了HttpSessinActivationListener的属性对象，必须通知
在序列化前钝化的或序列化后激活的session的监听器。
开发分布式的开发者应该清楚的是，一旦引擎运行在超过一个JVM的时候，就不能用static 表明变量来
存储应用状态，应该用EJB或数据库赖存储。
7.7.3客户端
因为cookies或SSL证书都是被web浏览器访问过程控制的，与任何特殊的window浏览器是没有关系的。
所以从所有window客户端到一个servlet引擎的请求是同一个会话的一部分。最好是开发者总是设想所
有的window客户端是一起参与同一个会话的。