我的 PHP 脚本缓存（公共）友好吗？
我已经完成了一个可以提供许多文档的小型 PHP 应用程序。这些文档必须可由客户端和代理缓存。
由于代理可以缓存我的结果，因此我必须格外小心，因为我提供的文档可以具有不同的 MIME 类型（基于 $_SERVER['HTTP_ACCEPT'] 的内容协商）和不同的语言（按此顺序：$_POST 值 / $_GET 值/ URL / PHP 会话值 / $_COOKIE 值 / $_SERVER['HTTP_ACCEPT_LANGUAGE'] / 默认脚本值）。
简而言之，一个页面可以使用许多 MIME 类型和多种语言来提供相同 URL（问题已更改：请参阅下面的编辑）。
为了帮助缓存代理，我将“Vary: Accept”标头与 ETag 标头结合使用。 ETag 是当前语言和最后修改时间戳的 MD5。
我总是：
- 发送 Expires 标头
- 发送 Cache-Control 标头
- 发送 Last-Modified 标头
- 发送 Content-Type 标头
- 发送 ETag 标头（基于当前语言和 Last-Modified 时间戳）
- 发送 Content-Language
- 发送“Vary:如果文档是 XHTML，则接受“标头
现在我的问题是：这是否足以帮助在代理和客户端上进行缓存？我错过了什么/标题吗？
为了帮助您，这里是测试页面的 HTTP 响应标头（在我的本地环境中）：
"
Date Wed, 30 Dec 2009 18:56:26 GMT
Server Apache/2.0.63 (Win32) PHP/5.1.0
X-Powered-By PHP/5.1.0
Set-Cookie Tests=697daqbmple2e1daq2dg74ur96; path=/
Expires Wed, 30 Dec 2009 21:56:26 GMT
Cache-Control public, max-age=10800
Last-Modified Mon, 28 Dec 2009 15:11:49 GMT
Etag "44fa50be4638161a596e4b75d6ab7a94"
Vary Accept
Content-Language en-us
Content-Length 3043
Keep-Alive timeout=15, max=100
Connection Keep-Alive
Content-Type application/xhtml+xml; charset=UTF-8
"
编辑：好的我明白，在这种情况下，提供具有许多 MIME 和 的文档，该文档具有不同的语言（可以来自来自如此多的来源 - 见上文）只是简单的糟糕设计。如果你想这样做，只需使用“私有”缓存（代理上没有缓存）......我对吗？
如果每种语言都有自己的 URL（但每个 URL 仍然可以提供许多 MIME），那么我当前的实现对于“公共”缓存（客户端 + 代理上的缓存）是否可以？
I have finalized a small PHP application that can serve many documents. These documents must be cacheable by clients and proxies.
Since proxies can cache my results I must be extra careful because the documents I serve can have different MIMEs types (content negotiation based on $_SERVER['HTTP_ACCEPT']) and different languages (based in this order: $_POST value / $_GET value / URL / PHP session value / $_COOKIE value / $_SERVER['HTTP_ACCEPT_LANGUAGE'] / default script value).
To shortly sum up, a page can be served with many MIME type and many languages with the same URL (question changed: see edit below).
To help cache on proxies I use the "Vary: Accept" header in combination with the ETag header. The ETags is a MD5 of the current language and the last modified timestamp.
I always:
- Send an Expires header
- Send a Cache-Control header
- Send a Last-Modified header
- Send a Content-Type header
- Send an ETag header (based on current language and Last-Modified timestamp)
- Send a Content-Language
- Send a "Vary: Accept" header if the document is XHTML
Now with my question: is this enough to help cache on proxies and clients? Did I miss a thing/header?
To help you, here’s the HTTP response header for a test page (on my local environment):
"
Date Wed, 30 Dec 2009 18:56:26 GMT
Server Apache/2.0.63 (Win32) PHP/5.1.0
X-Powered-By PHP/5.1.0
Set-Cookie Tests=697daqbmple2e1daq2dg74ur96; path=/
Expires Wed, 30 Dec 2009 21:56:26 GMT
Cache-Control public, max-age=10800
Last-Modified Mon, 28 Dec 2009 15:11:49 GMT
Etag "44fa50be4638161a596e4b75d6ab7a94"
Vary Accept
Content-Language en-us
Content-Length 3043
Keep-Alive timeout=15, max=100
Connection Keep-Alive
Content-Type application/xhtml+xml; charset=UTF-8
"
EDIT: OK I understand that in this case serving a document with many MIMEs and having different languages (that can come from so many sources - see above) is just plain bad design. If you want to do this just use "private" cache (no cache on proxies)... Am I correct?
If each language have it's own URL (but each URL can be served with many MIME still) is my current implementation is OK for a "public" cache (cache on clients + proxies)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
由于您的输出还取决于代理无法知道的内容（例如会话数据），因此将（不可缓存的）重定向发送到实际内容不是更容易吗？这对于给定的 URL（带参数）来说是固定的，因此更容易缓存。我知道这涉及额外的往返，但它可能不太容易出错，并且也会减少不完全理解/支持所有标头组合的代理的问题。
另外，我猜测，如果您有两个客户端通过相同的代理但使用不同的语言 cookie，则您当前的方法将为同一 URL 返回两个不同的 ETag，这将使代理在每次看到其他客户端。
Since your output also depends on things a proxy cannot know like session data, won't it be easier to send a (non-cachable) redirect to the actual content, which would be fixed for a given URL (with parameters) and therefore much easier to cache. I know this involves an extra round-trip, but it's probably much less error-prone and would also cause less problems with proxies that don't completely understand/support all your header combinations.
Also, I'm guessing that, if you have two clients going through the same proxy but with different language cookies, your current method would return two different ETags for the same URL, which would make the proxy update its copy each time it sees the other client.
我相信原则上你应该没问题——添加 Vary 标头意味着缓存应该保存数据的多个实例，并由 ETag 键入。
不过，我要指出的是，您不仅在 Accept 上有所不同，而且在 Cookie 和 Accept-Language 上也有所不同。通过 cookie 进行变化意味着代理必须验证每个请求，但应该能够使用 If-None-Match 标头让服务器指示应使用哪个（已缓存）ETag。
I believe you should be fine in principle -- adding the Vary header means that caches should hold multiple instances of your data, keyed by ETag.
I would note, though, that you don't only vary on Accept, you also vary on Cookie and Accept-Language. Varying by cookie means that the proxy will have to validate every request, but should be able to use an If-None-Match header to let the server indicate which (already cached) ETag should be used.
如果“Accept”和“Accept-Language”的响应都不同，则需要在“Vary”响应标头中提及两者。
If the response varies both on "Accept" and "Accept-Language", then both need to be mentioned in the "Vary" response header.