有谁知道是否有什么奇怪的事情发生？ 看来，我的反向代理设置，并不保留从原来的虚拟主机正确的caching头。
让我解释…
我目前正在使用PHP Slim为我的networking应用程序创build一个API。 它有自己的caching机制，安装和运行良好。 所以，例如在访问资源api.example.com/info ，我设置了一个Last-Modified ，它可以caching（不会经常更改）。
因此，标题看起来像这样：
Request URL:http://api.example.com/info Request Method:GET Status Code:304 Not Modified
请求头
Accept:text/html,application/xhtml xml,application/xml;q=0.9,*/*;q=0.8 Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3 Accept-Encoding:gzip,deflate,sdch Accept-Language:en-GB,en-US;q=0.8,en;q=0.6 Cache-Control:max-age=0 Connection:keep-alive Host:api.example.com If-Modified-Since:Mon, 04 Oct 2010 08:00:52 1100 User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5
响应头
Connection:Keep-Alive Date:Tue, 19 Jun 2012 22:34:45 GMT Keep-Alive:timeout=5, max=100 Server:Apache/2.2.21 (Win64) PHP/5.3.8 Vary:Accept-Encoding
其中显示资源返回304 – 它已从caching中检索。 大！
但是，Web应用程序通过反向代理访问此内容（跨域问题）。 当从app.example.com/api/info访问完全相同的资源时，它将返回一个200代码。 它也显着加载较慢，这让我觉得有些不工作。
这一次，标题是
Request URL:http://app.example.com/api/info Request Method:GET Status Code:200 OK
请求头
Accept:text/html,application/xhtml xml,application/xml;q=0.9,*/*;q=0.8 Accept-Charset:ISO-8859-1,utf-8;q=0.7,*;q=0.3 Accept-Encoding:gzip,deflate,sdch Accept-Language:en-GB,en-US;q=0.8,en;q=0.6 Cache-Control:max-age=0 Connection:keep-alive Host:app.example.com If-Modified-Since:Mon, 04 Oct 2010 08:00:52 GMT User-Agent:Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.56 Safari/536.5
响应头
Connection:Keep-Alive Content-Encoding:gzip Content-Length:1959 Content-Type:application/json Date:Tue, 19 Jun 2012 22:41:01 GMT Keep-Alive:timeout=5, max=100 Last-Modified:Mon, 04 Oct 2010 08:00:52 GMT Server:Apache/2.2.21 (Win64) PHP/5.3.8 Vary:Accept-Encoding X-API-Version:v1.0 X-Powered-By:PHP/5.3.8, Slim
有任何想法吗？ 对不起，大量的标题信息 – 不想忽略任何信息。
当我比较你的两个示例请求，我看到他们之间的一些更多的差异。
例如第二个响应（通过代理）包括一个
Content-Encoding:gzip
线。 也许你的反向代理在交付结果之前添加一个gzip压缩filter。 可能意味着：你的主要资源没有改变，但是代理通过压缩来改变内容，所以它将其标记为“新内容”。
另一个区别在于您的请求：在您的第一个请求中，您发送：
If-Modified-Since:Mon, 04 Oct 2010 08:00:52 +1100
但在第二次请求中，时间偏差+1100丢失，所以你发送另一个修改时间。