HTTP Last-modified/Etag
http://www.cnblogs.com/rongxh7/archive/2010/05/15/1736291.html
基础知识
1)什么是”Last-Modified”?
在浏览器第一次请求某一个URL时，服务器端的返回状态会是200，内容是你请求的资源，同时有一个Last-Modified的属性标记此文件在服务期端最后被修改的时间，格式类似这样：
Last-Modified:Fri,12May200618:53:33GMT
客户端第二次请求此URL时，根据HTTP协议的规定，浏览器会向服务器传送If-Modified-Since报头，询问该时间之后文件是否有被修改过：
If-Modified-Since:Fri,12May200618:53:33GMT
如果服务器端的资源没有变化，则自动返回HTTP304（NotChanged.）状态码，内容为空，这样就节省了传输数据量。当服务器端代码发生改变或者重启服务器时，则重新发出资源，返回和第一次请求时类似。从而保证不向客户端重复发出资源，也保证当服务器有变化时，客户端能够得到最新的资源。
2)什么是”Etag”?
HTTP协议规格说明定义ETag为“被请求变量的实体值”（参见——章节14.19）。另一种说法是，ETag是一个可以与Web资源关联的记号（token）。典型的Web资源可以一个Web页，但也可能是JSON或XML文档。服务器单独负责判断记号是什么及其含义，并在HTTP响应头中将其传送到客户端，以下是服务器端返回的格式：
ETag:"50b1c1d4f775c61:df3"
客户端的查询更新格式是这样的：
If-None-Match:W/"50b1c1d4f775c61:df3"
如果ETag没改变，则返回状态304然后不返回，这也和Last-Modified一样。本人测试Etag主要在断点下载时比较有用。
Last-Modified和Etags如何帮助提高性能?
聪明的开发者会把Last-Modified和ETags请求的http报头一起使用，这样可利用客户端（例如浏览器）的缓存。因为服务器首先产生Last-Modified/Etag标记，服务器可在稍后使用它来判断页面是否已经被修改。本质上，客户端通过将该记号传回服务器要求服务器验证其（客户端）缓存。
过程如下:
1.客户端请求一个页面（A）。
2.服务器返回页面A，并在给A加上一个Last-Modified/ETag。
3.客户端展现该页面，并将页面连同Last-Modified/ETag一起缓存。
4.客户再次请求页面A，并将上次请求时服务器返回的Last-Modified/ETag一起传递给服务器。
5.服务器检查该Last-Modified或ETag，并判断出该页面自上次客户端请求之后还未被修改，直接返回响应304和一个空的响应体。
HttpClientRedirectsHandling
简介
这份文档简单介绍下HttpClient手动处理重定向功能。
因为某些原因，比如需要人工的支持或者HttpClient不支持又或者网络的限制（如需要特殊的权限才可以访问的资源），有些类型的重定向是HttpClient不能自动处理的。当前版本的HttpClient不能够自动处理POST和PUT方法的重定向。
手动处理重定向
介于300和399之间的状态码，都代表重定向。最常见的重定向状态码如下：
·301HttpStatus.SC_MOVED_PERMANENTLY，永久移除。
·302HtpStatus.SC_MOVED_TEMPORARILY，暂时移除。
·303HttpStatus.SC_SEE_OTHER，重定向到其他资源。
·307HttpStatus.SC_TEMPORARY_REDIRECT，临时重定向。
注意：有些3XX的状态码并不只是简单给发送请求标识一个不同的URL。这些状态码需要应用自行处理。
当应用程序收个一个简单的重定向Responses时，必须用新的URL去执行HttpMethod的executeMethod方法，重新下载新URL对应的资源。通常，我们采用递归的方式去处理重定向，以防有多个重定向，不过要加标识数去结束你的递归。
StringredirectLocation;
HeaderlocationHeader=method.getResponseHeader("location");
if(locationHeader!=null){
redirectLocation=locationHeader.getValue();
}else{
//Theresponseisinvalidanddidnotprovidethenewlocationfor
//theresource.Reportanerrororpossiblyhandletheresponse
//likea404NotFounderror.
}
StringredirectLocation;
HeaderlocationHeader=method.getResponseHeader("location");
if(locationHeader!=null){
redirectLocation=locationHeader.getValue();
}else{
//Theresponseisinvalidanddidnotprovidethenewlocationfor
//theresource.Reportanerrororpossiblyhandletheresponse
//likea404NotFounderror.
}
当得到新的Location以后，你可以对待一个新的URL一样，使用HttpClient去请求对应的资源。
开发过web应用的人，应该都知道http重定向这个功能，html就有最简单的方法：
<metahttp-equiv="refresh"content="5;url=http://www.cppblog.com/cool-liangbing/">，
也就是告诉你的浏览器5秒之后自动跳转到我的c++博客首页http://www.cppblog.com/cool-liangbing/。
重定向常常用于自动跳转，从活动空间来看大概分两类：服务器内部跳转和服务器之间跳转。
服务器内部跳转常见于“登陆成功！5秒之后将自动进入首页”这种应用。而服务器之间跳转，种类稍微
多一些：(1)从服务器内跳往外部服务器;(2)从A服务器跳转到B服务器，接着跳转到C服务器;
(3)从A服务器跳转到B服务器,业务处理完毕之后又跳转到A服务器;(4)从用户浏览器向A服务器
发送请求，在出口网关处进行重定向，如通过iptable之类，重定向到一个认证服务器B，返回一个
认证登陆的页面，当用户输入了正确的用户名和密码等，认证服务器B再通过http重定向到A服务器.
以上所说的4种模式，前3种不值一提，而第4种则有些问题，不是那么容易跳转成功的。
不管你的认证服务器B是用现在的tomcat还是resin，或者其它流行的web服务器，最后发现总是
不能从认证服务器B跳到A服务器.刚开始怀疑html那种方法不行，就改用javascript写法，改用jsp调用
方法，甚至直接在servlet里调用重定向接口，一一试遍，都失败了，这才怀疑可能不是程序写法上
的问题。
在万般无奈情况下，使用CommView工具来抓包看看，从tcp包本身、httprequest和httpresponse
包内容来看，看不出什么不对。但发现整个跳转只在一个tcp连接上进行，这使我想到iptable把向A服务器
的请求偷偷转发到认证服务器B,而浏览器还认为认证服务器B就是A服务器,所以只要这条tcp连接不断，
浏览器就一直认为这种映射关系正确，所以你怎么也跳转不到真正的目的地-A服务器.
但是我们用老版本httpd或thttpd做web服务器，则可以正常跳转，何故？http协议版本差别：
老版本httpd或thttpd采用http1.0协议，而tomcat和resin这些jsp容器最新版本，大都已经实现了http1.1
协议了，对我们这个问题就是connection是采用非持久的还是持久模式，提取两个版本协议说明:
(1)http1.0:
原文：Exceptforexperimentalapplications,currentpracticerequiresthat
theconnectionbeestablishedbytheclientpriortoeachrequestand
closedbytheserveraftersendingtheresponse.
翻译：实验室应用除外，当前的做法是客户端在每次请求之前建立连接，而服务器端在发送回应后关闭此连接。
(2)http1.1:
原文：InHTTP/1.0,mostimplementationsusedanewconnectionforeachrequest/responseexchange.
InHTTP/1.1,aconnectionmaybeusedforoneormorerequest/responseexchanges,
althoughconnectionsmaybeclosedforavarietyofreasons(seesection8.1).
翻译：在HTTP/1.0协议下，大多数HTTP服务器实现对每一个请求/应答使用一个新连接.而在HTTP/1.1协议下，一个或多个请求/应答使用同一个连接。
(section8.1详细说明了为什么这么做)
从协议上分析清楚之后，我们怎么解决上面那个现实问题？肯定不能使用http1.1这种持久性连接。
查了下tomcatdocment说明，默认实现了http1.1，现在版本的connector已经早不提供http1.0支持了，
难道我们要退回到http1.0的版本？那是多么痛苦的事情。再查查tomcat/conf/server.xml里关于connector
的配置,有一个参数connecttimeout,默认是20000ms,作为服务器不可能争对socketaccept()的，应该是
socketrecv()的超时，那么我们设置它为比我们<metahttp-equiv="refresh"content="5;url=xxx">里
秒数小就可以了，保证在跳转之前以前的tcp连接被tomcat服务器断开就可以了，当然iptable应该在认证成功
之后不再对这个上网用户发出的http请求重定向到认证服务器,这个很容易做到，暂不提细节。
最后附上UML图以方便理解：
http://www.cppblog.com/images/cppblog_com/cool-liangbing/auth.jpg