Http HEAD 在不同服务器上为同一资源返回不同的上次修改日期，为什么？
我们有一个通过 HTTP 获取资源的 Java 进程。我发现即使客户端修改了某个资源，它也无法正确拉取。深入研究后，我发现服务器上正在运行的进程的资源的上次修改日期与我从浏览器查看信息时看到的不匹配。然后我尝试从不同的服务器和我的笔记本电脑中获取它，两者都显示了正确的日期。
此后，我修补了该过程，以允许选择忽略存在的情况下的标题日期（但将是不正确的），但我真的很想知道为什么会发生这种情况。
此处供参考的是来自服务器的卷曲响应，该响应返回了错误的信息。
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 上运行。
任何人都可以为我解释一下这个问题以及我如何能够长期解决这个问题吗？
We have a Java process that fetches resources over HTTP. I discovered that one resource was not pulling correctly even after a client had modified it. Digging into it I found that on the server the process is running the Last-Modified date of the resource does not match what I see when I view info from a browser. I then tried fetching it from a different server and my laptop and both of those showed the correct date.
I've since patched the process to allow the option to Ignore the header date for cases when it exists (but will be incorrect) but I would really love to know why this happens.
For reference here is a curl response from the Server that returns the incorrect info.
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
And then the same request on a different server (also get the same results on my machine)
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
Both servers are running on Fedora 10.
Can anyone shed some light on this for me and how I might be able to fix this long term?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
那么你有2个服务器并且都返回不同的结果，即不一致问题（我基本上可以从Etag标头看到这一点）？
我的第一个猜测是缓存。是否有任何缓存处于活动状态？可能是缓存失效无法正常工作或 ttl（生存时间）设置太长。
作为测试，尝试使用陈旧数据重新启动计算机，并查看结果是否发生变化（通常在系统重新启动期间，大多数简单的缓存设置都会被刷新）。
资源最初来自哪种后端（数据库、文件系统、第三方服务）？
So you have 2 servers and both return different results, i.e. inconsistency problem (I can basically see this from Etag header)?
My first guess would be caching. Are the any caches active? Maybe the invaliation of cache doesn't work correctly or ttl (time-to-live) settings are too long.
As test have a try and fresh restart machine with stale data and see whether results change (usually during restart of systems most of the simple cache-setups are flushed).
Which kind of backend does the resource come from initially (database, file-system, 3rd party-service)?