Http HEAD 在不同服务器上为同一资源返回不同的 Last-Modified 日期，为什么？答案

【问题标题】：Http HEAD returning different Last-Modified dates on different servers for same resource, why?Http HEAD 在不同服务器上为同一资源返回不同的 Last-Modified 日期，为什么？
【发布时间】：2011-11-23 17:47:22
【问题描述】：

我们有一个通过 HTTP 获取资源的 Java 进程。我发现即使在客户修改后一个资源也没有正确提取。深入研究后，我发现在服务器上运行该进程的资源的 Last-Modified 日期与我从浏览器查看信息时看到的不匹配。然后我尝试从不同的服务器和我的笔记本电脑上获取它，它们都显示了正确的日期。

我已经对该过程进行了修补，以允许在存在的情况下忽略标题日期的选项（但会不正确），但我真的很想知道为什么会发生这种情况。

这里的参考是来自服务器的 curl 响应，它返回了不正确的信息。

HTTP/1.1 200 OK
Server: Sun-ONE-Web-Server/6.1
Date: Fri, 23 Sep 2011 14:16:57 GMT
Content-length: 132
Content-type: text/plain
Last-modified: Wed, 15 Sep 2010 21:58:20 GMT
Etag: "84-4c91417c" 
Accept-ranges: bytes

然后在不同的服务器上进行相同的请求（在我的机器上也得到相同的结果）

HTTP/1.1 200 OK
Server: Sun-ONE-Web-Server/6.1
Date: Fri, 23 Sep 2011 14:18:47 GMT
Content-length: 132
Content-type: text/plain
Last-modified: Fri, 23 Sep 2011 01:20:43 GMT
Etag: "84-4e7bdeeb"
Accept-ranges: bytes

两台服务器都在 Fedora 10 上运行。

谁能为我解释一下这个问题，以及我如何才能长期解决这个问题？

【问题讨论】：

标签： linux http curl

【解决方案1】：

所以你有 2 个服务器并且都返回不同的结果，即不一致的问题（我基本上可以从 Etag 标头中看到）？

我的第一个猜测是缓存。任何缓存是否处于活动状态？可能是缓存失效或者ttl（time-to-live）设置太长了。

作为测试，尝试使用陈旧数据重新启动机器并查看结果是否发生变化（通常在系统重新启动期间，大多数简单的缓存设置都会被刷新）。

资源最初来自哪种后端（数据库、文件系统、第 3 方服务）？

【讨论】：

嗨，对不起，我一直很忙，没有检查这个。我不熟悉在相关服务器上运行的任何缓存，我将不得不尝试深入了解。您是否知道默认情况下会在 Linux 机器上运行的任何服务。至于有问题的资源，它只是托管在第三方网络服务器上的文件系统上的一个文本文件。
它是什么样的文件系统（像 NFS 一样的网络系统）？您如何访问该文件？我想知道为什么使用 Sun-ONE-Web-Server。默认情况下，大多数 Linux 发行版通常都带有 Apache。你是自己安装的吗？也许你可以告诉更多你的要求（你只是通过 HTTP 文件内容“隧道”）？
它来自 Sun Web 服务器，因为我们提取的文件托管在第三方网站上。它只是一个文本文件，存在于他们的网络服务器的某个地方。正如我提到的，我们有一个定期读取此文件的 Java 进程，但是即使我使用 CURL 从命令行提取文件头信息，我也会得到相同的旧头日期。因此，我认为这与 Apache 没有任何关系，它甚至没有在该服务器上运行。我在想也许你的意思是有一些通用的缓存过程，这是一个我可能不熟悉的 linux 过程。
我知道 linux 中没有通用的缓存机制。我会看看服务器。也许您可以尝试重新启动服务器，如果内容是一致的/最新的，那么很可能服务器本身内部有一些缓存设置。也许有预设的 ETag 处理程序和缓存配置。
今天早上我有机会重新启动实例。不幸的是，我仍然看到旧的 Last-modified 日期。很奇怪。至少我有一个解决办法:)