#) です。
* ,
Vary: Cache-Control:
Vary: accept-encoding, accept-language... は、
Accept-Encoding: Accept-Language:
Vary: User-Agent
*
Vary: * 200 403
Vary: Vary:
Vary:
Variant-Vary: RFC 2068 2616 のようにして差分を分かりやすく書いたはずだったのですが、段落の移動とかのせいでぐちゃぐちゃで却って分かりにくくなったような気がしています。ごめんんさい。
順序は RFC 2616 base なので、削除部分を読み飛ばせば 2616 として読むことができます。
目視で差分取りつつ merge してるので、うっかり落とした単語とかがあるかもしれません。原文も併せて参照して下さい。
The Vary response-header field is used by a server to signal that the response entity was selected from the available representations of the response using server-driven negotiation (section 12). Field-names listed in Vary headers are those of request-headers. The Vary field value indicates either that the given set of header fields encompass the dimensions over which the representation might vary, or that the dimensions of variance are unspecified ("*") and thus may vary over any aspect of future requests.
Vary Vary 頭欄に列挙される欄名は要求頭欄のものです。
Vary 頭欄の値は、その頭欄の集合が表現が変化し得る範囲を含むことも、
変化の範囲が未指定 ("*")
で、従って将来の要求のどの角度によっても変化しうることをも示します。
The Vary field value indicates the set of request-header fields that fully determines, while the response is fresh, whether a cache is permitted to use the response to reply to a subsequent request without revalidation. For uncacheable or stale responses, the Vary field value advises the user agent about the criteria that were used to select the representation. A Vary field value of "*" implies that a cache cannot determine from the request headers of a subsequent request whether this response is the appropriate representation. See section 13.6 for use of the Vary header field by caches.
Vary 欄の値は、
キャッシュが、要求が新鮮な間において、
再検証すること無しにその応答を後続の要求に返信するのに使うことが認められるかを完全に決定する要求頭欄の集合を示します。
キャッシュ不能であるか、又は新鮮でない応答に対しては、
Vary 欄の値は、
表現を選択するのに使われた基準をVary 欄の値 "*" は、キャッシュが、
この応答が後続の要求に対して適切な表現であるかどうかをその要求頭だけから決定出来ないことを示します。
キャッシュの Vary
頭欄の使用については13.6節 (
Vary = "Vary" ":" ( "*" | 1#field-name )An HTTP/1.1 server
MUSTSHOULD include an appropriateVary header field with any cacheable response that is subject to server-driven negotiation. Doing so allows a cache to properly interpret future requests on that resource and informs the user agent about the presence of negotiation on that resource. A serverSHOULDMAY include an appropriateVary header field with a non-cacheable response that is subject to server-driven negotiation, since this might provide the user agent with useful information about the dimensions over which the responsemight varyvaries at the time of the response.
適切な
Vary 頭欄を含めなければなりませんるべきです。
そうすることで、キャッシュが将来の要求を適切に解釈することが出来ますし、利用者エージェントにその資源についての折衝があったことを知らせることとなります。
サーバーは、サーバー駆動折衝の対象であるキャッシュ可能でない資源についても、適切な
Vary 頭欄を含めるべきですても構いません。
というのは、これによって、利用者エージェントに変化し得る応答の時点での応答の変種の規模についての有用な情報を提供することが出来るのです。
(RFC 2068 では次は
(RFC 2068 では
A Vary field value consisting of a list of field-names signals that the representation selected for the response is based on a selection algorithm which considers ONLY the listed request-header field values in selecting the most appropriate representation. A cache MAY assume that the same selection will be made for future requests with the same values for the listed field names, for the duration of time for which the response is fresh.
Vary 欄の値は、欄名の一覧で構成します。
これは、最も適切な表現を選択するに当たって、
列挙された要求頭欄の値のみを考慮する選択算法に基づいて、その応答の表現が選ばれたことを表します。
キャッシュは、応答が新鮮である時間内においては、
列挙された欄名に対して同じ値を持った将来の要求があった時に同じ選択がなされるものと仮定しても構いません。
The field-names given are not limited to the set of standard request-header fields defined by this specification. Field names are case-insensitive.
(RFC 2068 では
(RFC 2068 では
A Vary field value of "*" signals that unspecified parameters
,possibly other than the contents ofnot limited to the request-headers (e.g., the network address of the client), play a role in the selection of the response representation.Subsequent requests on that resource can only be properly interpreted by the origin server, and thus a cache MUST forward a (possibly conditional) request even when it has a fresh response cached for the resource. See section 13.6 for use of the Vary header by caches.The "*" value MUST NOT be generated by a proxy server; it may only be generated by an origin server.
Vary 欄の "*"
という値は、要求頭に限らない、記述されていない変数
(例えばクライアントのネットワーク・アドレス)
が応答の表現の選択に影響したことを表します。 この資源に対する後続の要求は、源サーバーによってのみ適切に解釈され得、従ってキャッシュは、その資源の新鮮な応答がキャッシュされていても、 (おそらく条件付で) 要求を転送しなければなりません。 串サーバーは "*" という値を生成してはなりません。源サーバーのみがこの値を生成できます。
(RFC 2068 では
Use of server-driven content negotiation (section 12.1), as indicated by the presence of a Vary header field in a response, alters the conditions and procedure by which a cache can use the response for subsequent requests. See section 14.44 for use of the Vary header field by servers.
Vary
頭欄が応答中に現れることで示される通り、
キャッシュが後続の要求に対してその応答を使用することで状態と手続きが変更されます。 サーバーによる Vary 頭欄の使用については 14.4 節 (
(RFC 2068 での
A server MUST use the Vary header field (section 14.43) to inform a cache of what header field dimensions are used to select among multiple representations of a cachable response. A cache may use the selected representation (the entity included with that particular response) for replying to subsequent requests on that resource only when the subsequent requests have the same or equivalent values for all header fields specified in the Vary response-header. Requests with a different value for one or more of those header fields would be forwarded toward the origin server.
If an entity tag was assigned to the representation, the forwarded request SHOULD be conditional and include the entity tags in an If- None-Match header field from all its cache entries for the Request- URI. This conveys to the server the set of entities currently held by the cache, so that if any one of these entities matches the requested entity, the server can use the ETag header in its 304 (Not Modified) response to tell the cache which entry is appropriate. If the entity-tag of the new response matches that of an existing entry, the new response SHOULD be used to update the header fields of the existing entry, and the result MUST be returned to the client.
The Vary header field may also inform the cache that the representation was selected using criteria not limited to the request-headers; in this case, a cache MUST NOT use the response in a reply to a subsequent request unless the cache relays the new request to the origin server in a conditional request and the server responds with 304 (Not Modified), including an entity tag or Content-Location that indicates which entity should be used.
(
(RFC 2068 では
A server SHOULD use the Vary header field to inform a cache of what request-header fields were used to select among multiple representations of a cacheable response subject to server-driven negotiation. The set of header fields named by the Vary field value is known as the "selecting" request-headers.
Vary 頭欄を使用するのが良いです。
Vary 欄の値に挙げられた頭欄の集合は
「選択」要求頭とも呼ばれます。
When the cache receives a subsequent request whose Request-URI specifies one or more cache entries including a Vary header field, the cache MUST NOT use such a cache entry to construct a response to the new request unless all of the selecting request-headers
named in the cached Vary header arepresent in the new request match the corresponding stored request-headers in the original request.
Request-URI が Vary
頭欄を含むキャッシュ項目を1つ以上指定している後続の要求をキャッシュが受信した時は、
キャッシュは新しい要求にある全てのキャッシュされた 選択要求頭がVary 頭に名前が挙げられた出現する保管している元の要求の対応する要求頭と一致するので無い限り、
新しい要求への応答を構築するのにそのようなキャッシュ項目を使ってはなりません。
The selecting request-headers from two requests are defined to match if and only if the selecting request-headers in the first request can be transformed to the selecting request-headers in the second request by adding or removing linear white space (LWS) at places where this is allowed by the corresponding BNF, and/or combining multiple message-header fields with the same field name following the rules about message headers in section 4.2.
(RFC 2068 では
A Vary header field-value of "*" always fails to match and subsequent requests on that resource can only be properly interpreted by the origin server.
Vary 頭欄の値が "*" の時には、
その資源への後続の要求は源サーバーによってのみ適切に解釈出来るので、
絶対に一致しません。
If the selecting request header fields for the cached entry do not match the selecting request header fields of the new request, then the cache MUST NOT use a cached entry to satisfy the request unless it first relays the new request to the origin server in a conditional request and the server responds with 304 (Not Modified), including an entity tag or Content-Location that indicates the entity to be used.
Content-Location
を含んだ 304 (未修正)
のサーバー応答を受け取った場合を除きます。
If an entity tag was assigned to a cached representation, the forwarded request SHOULD be conditional and include the entity tags in an If-None-Match header field from all its cache entries for the resource. This conveys to the server the set of entities currently held by the cache, so that if any one of these entities matches the requested entity, the server can use the ETag header field in its 304 (Not Modified) response to tell the cache which entry is appropriate. If the entity-tag of the new response matches that of an existing entry, the new response SHOULD be used to update the header fields of the existing entry, and the result MUST be returned to the client.
If-None-Match 頭欄に含めるべきです。
これによってサーバーに現在キャッシュが保持している実体の集合を伝えることが出来て、
その実体のいずれかが要求された実体と一致していれば、サーバーは
ETag
頭欄を使用することでキャッシュのどの実体が適切か教えることが出来ます。
新しい応答の実体札が既存の項目と一致したなら、
新しい応答は既存の項目の頭欄を更新するのに使うべきで、
その結果はクライアントに返さなければなりません。
If any of the existing cache entries contains only partial content for the associated entity, its entity-tag SHOULD NOT be included in the If-None-Match header field unless the request is for a range that would be fully satisfied by that entry.
If-None-Match 頭欄に含めるべきではありません。
If a cache receives a successful response whose Content-Location field matches that of an existing cache entry for the same Request-URI, whose entity-tag differs from that of the existing entry, and whose Date is more recent than that of the existing entry, the existing entry SHOULD NOT be returned in response to future requests and SHOULD be deleted from the cache.
Content-Location 欄が同じ Request-URI
に対する既存のキャッシュ項目のものと一致し、
その実体札は既存の項目のものとは異なるもので、
Date は既存の項目のものより最近であるのなら、
既存の項目は将来の要求の応答として返すべきではなく、
キャッシュから削除するべきです。
If a HTTP/1.1 [1] server can generate varying responses for a request on some resource, then the server MUST include a Vary header in these responses if they are cacheable. This Vary header is a signal to HTTP/1.1 caches that something special is going on. It prevents the caches from returning the currently chosen response for every future request on the resource.
HTTP/1.1 サーバーがなんかの資源に対する要求で変化する応答を生成することができるときは、
サーバーはその応答がVary 頭は HTTP/1.1 キャッシュに何か特別なことをしているのだと通知します。
これによってキャッシュが現在選ばれた応答をその資源についての将来の要求に返さないようにします。
Servers engaging in transparent content negotiation will generate varying responses. Therefore, cacheable list, choice, and adhoc responses MUST always include a Vary header.
The most simple Vary header which can be included is
- Vary: *
This header leaves the way in which the response is selected by the server completely unspecified.
A more elaborate Vary header MAY be used to allow for certain optimizations in HTTP/1.1 caches which do not have specific optimizations for transparent content negotiation, but which do cache multiple variant responses for one resource. Such a more elaborate Vary header lists all request headers which can be used by the server when selecting a response for a request on the resource.
より詳細な Vary 頭を使用して透過内容折衝には特に最適化しないけれども一つの資源についての複数の変種資源はキャッシュする
HTTP/1.1 キャッシュでの最適化を可能にしても構いません。
そのようなより詳細な Vary 頭は、サーバーがその資源についての要求に対する応答を選択するときに使用することが出来るすべての要求頭を列挙します。
Origin servers can construct a more elaborate Vary header in the following way. First, start with the header
起源サーバーは次の方法でより詳細な Vary
頭欄を構築できます。まず、頭
- Vary: negotiate
`negotiate' is always included because servers use the information in the Negotiate header when choosing between a list, choice, or adhoc response.
から始めます。 negotiate はサーバーが
Then, if any of the following attributes is present in any variant description in the Alternates header, add the corresponding header name to the Vary header
それから、 Vary 頭に追加します。
attribute | header name to add
-----------+---------------------
type | accept
charset | accept-charset
language | accept-language
features | accept-featuresThe Vary header constructed in this way specifies the response variation which can be caused by the use of a variant selection algorithm in proxies. If the origin server will in some cases, for example if contacted by a non-negotiating user agent, use a custom negotiation algorithm which takes additional headers into account, these names of these headers SHOULD also be added to the Vary header.
この方法で構築された Vary 頭は串で変種選択算法を使用したときに起こり得る応答変種を指定します。
起源サーバーが、例えば非折衝利用者エージェントにより接触を受けた場合など幾つかの場合では、
追加の頭を考慮に入れた個別折衝算法を使用するのであれば、
その頭の名前も Vary 頭に追加するべきです。
A proxy cache cannot construct an elaborate vary header using the method above, because this method requires exact knowledge of any custom algorithms present in the origin server. However, when extracting an Alternates header from a response (section 10.4) caches MAY also extract the Vary header in the response, and reuse it along with the Alternates header. A clean Vary header can however only be extracted if the variant does not vary itself, i.e. if a Variant-Vary header is absent.
前述の方法は起源サーバーでどんな個別算法を使ったかの正確な知識が必要となるので、
この方法を使って串キャッシュが詳細な変化頭を構築することは出来ません。
しかし、応答から Alternates 頭を取り出すときには、
キャッシュは応答から Vary
頭をも取り出して、 Alternates 頭と一緒に再利用しても構いません。
しかし、綺麗な Vary 頭を取り出すことが出来るのは、
変種自体が変化しない時、つまり
Vary: 欄の値になるものを
* と同じ意味になるわけですが。
Vary: 欄の使い方についても言及があるので、ぜひ読んでおきましょう。
# で定義されてはいないため。) のですが、ちょっとまずくありません?Vary に加えると間違って解説しているところがありますが、正しくは Accept-Language を加える、です。クライアントからの受入れ言語申告に基づき折衝するのですから。Content-Language で正しいですが、そんな場面ってあるでしょうか?
For HEAD and GET requests, if the server supports content negotiation by format or JSON-LD profile, the response must have a Vary header with Accept in the value [rfc7231].
Googlebot がモバイル端末向けのコンテンツを迅速に検出できるようになります。有効な Vary HTTP ヘッダーは、モバイル端末向けコンテンツを配信する URL をクロールする際に利用できるシグナルです。
パソコンサイトにアクセスしたモバイル ユーザーをモバイルサイトに自動的にリダイレクトする場合(またはその逆の場合)は、Vary HTTP ヘッダーを含めるようにサーバーを必ず設定してください。