HTTP缓存ETAG和Last-Modified

基础知识
        1) 什么是”Last-Modified”? 

        在浏览器第一次请求某一个URL时，服务器端的返回状态会是200，内容是你请求的资源，同时有一个Last-Modified的属性标记此文件在服务期端最后被修改的时间，格式类似这样： 

        Last-Modified: Fri, 12 May 2006 18:53:33 GMT 

        客户端第二次请求此URL时，根据 HTTP 协议的规定，浏览器会向服务器传送 If-Modified-Since 报头，询问该时间之后文件是否有被修改过： 

        If-Modified-Since: Fri, 12 May 2006 18:53:33 GMT 

        如果服务器端的资源没有变化，则自动返回 HTTP 304 （Not Changed.）状态码，内容为空，这样就节省了传输数据量。 当服务器端代码发生改变或者重启服务器时，则重新发出资源，返回和第一次请求时类似。从而保证不向客户端重复发出资源，也保证当服务器有变化时，客户端能 够得到最新的资源。 

        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和一个空的响应体。

 

 

 

HttpClient Redirects Handling

简介

 

这份文档简单介绍下 HttpClient 手动处理重定向功能。

 

因为某些原因，比如需要人工的支持或者 HttpClient 不支持又或者网络的限制（如需要特殊的权限才可以访问的资源），有些类型的重定向是 HttpClient 不能自动处理的。当前版本的 HttpClient 不能够自动处理 POST 和 PUT 方法的重定向。

 

手动处理重定向

 

介于 300 和 399 之间的状态码，都代表重定向。最常见的重定向状态码如下：

·        301 HttpStatus.SC_MOVED_PERMANENTLY ，永久移除。

·        302 HtpStatus.SC_MOVED_TEMPORARILY ，暂时移除。

·        303 HttpStatus.SC_SEE_OTHER ，重定向到其他资源。

·        307 HttpStatus.SC_TEMPORARY_REDIRECT ，临时重定向。

注意：有些 3XX 的状态码并不只是简单给发送请求标识一个不同的 URL 。这些状态码需要应用自行处理。

 

当应用程序收个一个简单的重定向 Responses 时，必须用新的 URL 去执行 HttpMethod 的 executeMethod 方法，重新下载新 URL 对应的资源。通常，我们采用递归的方式去处理重定向，以防有多个重定向，不过要加标识数去结束你的递归。

 

String redirectLocation;

        Header locationHeader = method.getResponseHeader("location");

        if (locationHeader != null) {

            redirectLocation = locationHeader.getValue();

         } else {

            // The response is invalid and did not provide the new location for

            // the resource.  Report an error or possibly handle the response

            // like a 404 Not Found error.

        }

String redirectLocation;

         Header locationHeader = method.getResponseHeader("location");

        if (locationHeader != null) {

            redirectLocation = locationHeader.getValue();

        } else {

            // The response is invalid and did not provide the new location for

            // the resource.  Report an error or possibly handle the response

            // like a 404 Not Found error.

        }

 

当得到新的 Location 以后，你可以对待一个新的 URL 一样，使用 HttpClient 去请求对应的资源。

 

开发过web应用的人，应该都知道http重定向这个功能，html就有最简单的方法：
<meta http-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包本身、http request和http response
包内容来看，看不出什么不对。但发现整个跳转只在一个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: 
     原文：Except for experimental applications, current practice requires that
      the connection be established by the client prior to each request and
      closed by the server after sending the response. 
     翻译：实验室应用除外，当前的做法是客户端在每次请求之前建立连接，而服务器端在发送回应后关闭此连接。
      (2) http1.1:
     原文：In HTTP/1.0, most implementations used a new connection for each request/response exchange. 
    In HTTP/1.1, a connection may be used for one or more request/response exchanges, 
    although connections may be closed for a variety of reasons (see section 8.1). 
     翻译：在HTTP/1.0协议下，大多数HTTP服务器实现对每一个请求/应答使用一个新连接. 而在HTTP/1.1协议下，一个或多个请求/应答使用同一个连接。
     (section 8.1详细说明了为什么这么做)
       从协议上分析清楚之后，我们怎么解决上面那个现实问题？肯定不能使用http1.1这种持久性连接。
查了下tomcat docment说明，默认实现了http1.1，现在版本的connector已经早不提供http1.0支持了，
难道我们要退回到http1.0的版本？那是多么痛苦的事情。再查查tomcat/conf/server.xml里关于connector
的配置,有一个参数connecttimeout,默认是20000ms, 作为服务器不可能争对socket accept()的，应该是
socket recv()的超时，那么我们设置它为比我们<meta http-equiv="refresh" content="5;url=xxx">里
秒数小就可以了，保证在跳转之前以前的tcp连接被tomcat服务器断开就可以了，当然iptable应该在认证成功
之后不再对这个上网用户发出的http请求重定向到认证服务器, 这个很容易做到，暂不提细节。
       最后附上UML图以方便理解：