“ Vary: Accept”HTTP 头的功能是什么？

我使用 PHP 生成动态网页。如下面的教程所述(参见下面的链接) ，当 $_ SERVER [‘ HTTP _ ACCEPT’]允许时，XHTML 文档的 MIME 类型应该是“ application/XHTML + xml”。由于您可以使用2个不同的 MIME (“ application/xhtml + xml”和“ text/html”)为同一个页面提供服务，因此您应该将“ Vary”HTTP 头设置为“ Accept”。这将有助于代理上的缓存。

连结: Http://keystonewebsites.com/articles/mime_type.php

现在我不确定这句话的含义: 头(‘ Vary: Accept’) ; 我真的不知道“变化: 接受”究竟会做什么... ..。

我找到的唯一解释是:

在 Content-Type 标头之后，有一个 Vary 头被发送到(如果我理解它 正确地)告诉中间缓存, 像代理服务器一样，内容 文件类型视乎个别情况而有所不同 客户的能力 请求文件。 Http://www.456bereastreet.com/archive/200408/content_negotiation/

任何人都可以给我一个“真正”的解释这个头(这个价值)。我想我理解这样的事情: 接受-编码 代理上的缓存可以基于所服务页面的编码，但我不明白: 接受

78173 次浏览
小开
最佳答案

  • The cache-control header is the primary mechanism for an HTTP server to tell a caching proxy the "freshness" of a response. (i.e., how/if long to store the response in the cache)

  • In some situations, cache-control directives are insufficient. A discussion from the HTTP working group is archived here, describing a page that changes only with language. This is not the correct use case for the vary header, but the context is valuable for our discussion. (Although I believe the Vary header would solve the problem in that case, there is a Better Way.) From that page:

Vary is strictly for those cases where it's hopeless or excessively complicated for a proxy to replicate what the server would do.

A contrived example:

Your HTTP server has a large landing page. You have two slightly different pages with the same URL, depending if the user has been there before. You distinguish between requests and a user's "visit count" based on Cookies. But -- since your server's landing page is so large, you want intermediary proxies to cache the response if possible.

The URL, Last-Modified and Cache-Control headers are insufficient to give this insight to a caching proxy, but if you add Vary: Cookie, the cache engine will add the Cookie header to its caching decisions.

Finally, for small traffic, dynamic web sites -- I have always found the simple Cache-Control: no-cache, no-store and Pragma: no-cache sufficient.

Edit -- to more precisely answer your question: the HTTP request header 'Accept' defines the Content-Types a client can process. If you have two copies of the same content at the same URL, differing only in Content-Type, then using Vary: Accept could be appropriate.

Update 11 Sep 12:

I'm including a couple links that have appeared in the comments since this comment was originally posted. They're both excellent resources for real-world examples (and problems) with Vary: Accept; Iif you're reading this answer you need to read those links as well.

The first, from the outstanding EricLaw, on Internet Explorer's behavior with the Vary header and some of the challenges it presents to developers: Vary Header Prevents Caching in IE. In short, IE (pre IE9) does not cache any content that uses the Vary header because the request cache does not include HTTP Request headers. EricLaw (Eric Lawrence in the real world) is a Program Manager on the IE team.

The second is from Eran Medan, and is an on-going discussion of Vary-related unexpected behavior in Chrome: Backing doesn't handle Vary header correctly. It's related to IE's behavior, except the Chrome devs took a different approach -- though it doesn't appear to have been a deliberate choice.

小开

Vary: Accept simply says that the response was generated based on the Accept header in the request. A request with a different Accept header might get a different response.

(You can see that the linked PHP code looks at $HTTP_ACCEPT. That's the value of the Accept request header.)

To HTTP caches, this means that the response must be cached with extra care. It is only going to be a valid match for later requests with exactly the same Accept header.

Now this only matters if the page is cacheable in the first place. By default, PHP pages aren't. A PHP page can mark the output as cacheable by sending certain headers (Expires, for example). But whether and how to do that is a different question.

小开

This google webmaster video has a very good explanation about HTTP Vary header.

小开

There are actually a significant number of new features coming soon (and already in Chrome) that make the Vary header extremely useful. For example, consider Client Hinting. When used in connection with images, for example, client hinting allows a server to optimize resources such as images depending on:

  • Image Width
  • Viewport Width
  • Type of encoding supported by browser (think WebP)
  • Downlink (essentially network speed)

So a server which supports those features would set the Vary header to indicate that.

Chrome advertises WebP support by setting "image/webp" as part of the Vary header for each request. So a server might rewrite an image as WebP if the browser supports it, so the proxy would need to check the header so as to not cache a WebP image and then serve it to a browser that doesn't support WebP. Obviously, if your server doesn't do that, it wouldn't matter. So since the server's response varies on the Accept request header, the response must include that so as not to confuse proxies: 

Vary: Accept

Another example might be image width. On a mobile browser the Width header might be quite small for a responsive image, in comparison with what it would be if viewed from a desktop browser. So in that case Width would be added to the the Vary header is essential for proxy to not cache the small mobile version and serve it to desktop browsers, or vice versa. In that case, the header might include:

Vary: Accept, Width

Or in the case that a server supported all of the client hinting specs, the header would be something like:

Vary: Accept, DPR, Width, Save-Data, Downlink

提交答案