メインコンテンツまでスキップ

4. Constructing Responses from Caches (从缓存构建响应)

🇬🇧 English​

When presented with a request, a cache MUST NOT reuse a stored response, unless:

  • The presented effective request URI (Section 5.5 of [RFC7230]) and that of the stored response match, and
  • the request method associated with the stored response allows it to be used for the presented request, and
  • selecting header fields nominated by the stored response (if any) match those presented (see Section 4.1), and
  • the presented request does not contain the no-cache pragma (Section 5.4), nor the no-cache cache directive (Section 5.2.1), unless the stored response is successfully validated (Section 4.3), and
  • the stored response does not contain the no-cache cache directive (Section 5.2.2.2), unless it is successfully validated (Section 4.3), and
  • the stored response is either:
    • fresh (see Section 4.2), or
    • allowed to be served stale (see Section 4.2.4), or
    • successfully validated (see Section 4.3).

Note that any of the requirements listed above can be overridden by a cache-control extension; see Section 5.2.3.

When a stored response is used to satisfy a request without validation, a cache MUST generate an Age header field (Section 5.1), replacing any present in the response with a value equal to the stored response's current_age; see Section 4.2.3.

A cache MUST write through requests with methods that are unsafe (Section 4.2.1 of [RFC7231]) to the origin server; i.e., a cache is not allowed to generate a reply to such a request before having forwarded the request and having received a corresponding response.

Also, note that unsafe requests might invalidate already-stored responses; see Section 4.4.

When more than one suitable response is stored, a cache MUST use the most recent response (as determined by the Date header field). It can also forward the request with "Cache-Control: max-age=0" or "Cache-Control: no-cache" to disambiguate which response to use.

A cache that does not have a clock available MUST NOT use stored responses without revalidating them upon every use.

🇨🇳 中文​

当呈现请求时，缓存不得 (MUST NOT) 重用存储的响应，除非:

  • 呈现的有效请求URI（[RFC7230] 的第5.5节）与存储响应的URI匹配，并且
  • 与存储响应关联的请求方法允许其用于呈现的请求，并且
  • 存储响应指定的选择头字段（如果有）与呈现的头字段匹配（见第4.1节），并且
  • 呈现的请求不包含no-cache编译指示（第5.4节）或no-cache缓存指令（第5.2.1节），除非存储的响应已成功验证（第4.3节），并且
  • 存储的响应不包含no-cache缓存指令（第5.2.2.2节），除非已成功验证（第4.3节），并且
  • 存储的响应满足以下条件之一:
    • 新鲜的（见第4.2节），或
    • 允许提供过期服务（见第4.2.4节），或
    • 已成功验证（见第4.3节）。

请注意，上述任何要求都可以被缓存控制扩展覆盖; 见第5.2.3节。

当使用存储的响应来满足请求而无需验证时，缓存必须 (MUST) 生成Age头字段（第5.1节），用等于存储响应的current_age的值替换响应中存在的任何值; 见第4.2.3节。

缓存必须 (MUST) 将具有不安全方法（[RFC7231] 的第4.2.1节）的请求写入源服务器; 即，缓存不允许在转发请求并接收到相应响应之前生成对此类请求的回复。

另外，请注意，不安全的请求可能会使已存储的响应失效; 见第4.4节。

当存储多个合适的响应时，缓存必须 (MUST) 使用最新的响应（由Date头字段确定）。它还可以使用"Cache-Control: max-age=0"或"Cache-Control: no-cache"转发请求，以消除使用哪个响应的歧义。

没有时钟可用的缓存不得 (MUST NOT) 在每次使用时不重新验证的情况下使用存储的响应。

🇯🇵 日本語​

リクエストが提示された場合、キャッシュは、次の条件を満たさない限り、保存されたレスポンスを再利用してはならない (MUST NOT):

  • 提示された有効なリクエストURI（[RFC7230] のセクション5.5）と保存されたレスポンスのURIが一致し、かつ
  • 保存されたレスポンスに関連付けられたリクエストメソッドが、提示されたリクエストに使用されることを許可しており、かつ
  • 保存されたレスポンスによって指定された選択ヘッダーフィールド（ある場合）が、提示されたものと一致し（セクション4.1参照）、かつ
  • 提示されたリクエストにno-cacheプラグマ（セクション5.4）もno-cacheキャッシュディレクティブ（セクション5.2.1）も含まれていない、または保存されたレスポンスが正常に検証されている（セクション4.3）、かつ
  • 保存されたレスポンスにno-cacheキャッシュディレクティブ（セクション5.2.2.2）が含まれていない、または正常に検証されている（セクション4.3）、かつ
  • 保存されたレスポンスが次のいずれかである:
    • 新鮮である（セクション4.2参照）、または
    • 古い状態で提供することが許可されている（セクション4.2.4参照）、または
    • 正常に検証されている（セクション4.3参照）。

上記の要件のいずれも、キャッシュ制御拡張によって上書きできることに注意すること; セクション5.2.3を参照。

検証なしで保存されたレスポンスを使用してリクエストを満たす場合、キャッシュはAgeヘッダーフィールド（セクション5.1）を生成しなければならず (MUST)、レスポンスに存在する任意の値を保存されたレスポンスのcurrent_ageに等しい値で置き換える; セクション4.2.3を参照。

キャッシュは、安全でないメソッド（[RFC7231] のセクション4.2.1）を持つリクエストをオリジンサーバーに書き込まなければならない (MUST); つまり、キャッシュは、リクエストを転送し、対応するレスポンスを受信する前に、そのようなリクエストへの返信を生成することは許可されていない。

また、安全でないリクエストは、すでに保存されているレスポンスを無効にする可能性があることに注意すること; セクション4.4を参照。

複数の適切なレスポンスが保存されている場合、キャッシュは最新のレスポンス（Dateヘッダーフィールドによって決定される）を使用しなければならない (MUST)。また、"Cache-Control: max-age=0"または"Cache-Control: no-cache"でリクエストを転送して、どのレスポンスを使用するかを明確にすることもできる。

時計が利用できないキャッシュは、毎回使用する際に再検証することなく、保存されたレスポンスを使用してはならない (MUST NOT)。

🇫🇷 Français​

Lorsqu'une requête est présentée, un cache NE DOIT PAS (MUST NOT) réutiliser une réponse stockée, sauf si :

  • L'URI de requête effective présentée (Section 5.5 de [RFC7230]) et celle de la réponse stockée correspondent, et
  • la méthode de requête associée à la réponse stockée permet son utilisation pour la requête présentée, et
  • les champs d'en-tête de sélection désignés par la réponse stockée (le cas échéant) correspondent à ceux présentés (voir Section 4.1), et
  • la requête présentée ne contient pas le pragma no-cache (Section 5.4), ni la directive de cache no-cache (Section 5.2.1), sauf si la réponse stockée est validée avec succès (Section 4.3), et
  • la réponse stockée ne contient pas la directive de cache no-cache (Section 5.2.2.2), sauf si elle est validée avec succès (Section 4.3), et
  • la réponse stockée est soit :
    • fraîche (voir Section 4.2), ou
    • autorisée à être servie périmée (voir Section 4.2.4), ou
    • validée avec succès (voir Section 4.3).

Notez que l'une quelconque des exigences énumérées ci-dessus peut être remplacée par une extension de contrôle de cache ; voir Section 5.2.3.

Lorsqu'une réponse stockée est utilisée pour satisfaire une requête sans validation, un cache DOIT (MUST) générer un champ d'en-tête Age (Section 5.1), en remplaçant tout champ présent dans la réponse par une valeur égale au current_age de la réponse stockée ; voir Section 4.2.3.

Un cache DOIT (MUST) transmettre directement les requêtes avec des méthodes non sûres (Section 4.2.1 de [RFC7231]) au serveur d'origine ; c'est-à-dire qu'un cache n'est pas autorisé à générer une réponse à une telle requête avant d'avoir transféré la requête et reçu une réponse correspondante.

De plus, notez que les requêtes non sûres peuvent invalider des réponses déjà stockées ; voir Section 4.4.

Lorsque plusieurs réponses appropriées sont stockées, un cache DOIT (MUST) utiliser la réponse la plus récente (telle que déterminée par le champ d'en-tête Date). Il peut également transférer la requête avec "Cache-Control : max-age=0" ou "Cache-Control : no-cache" pour lever l'ambiguïté sur la réponse à utiliser.

Un cache qui ne dispose pas d'une horloge NE DOIT PAS (MUST NOT) utiliser des réponses stockées sans les revalider à chaque utilisation.

🇩🇪 Deutsch​

Wenn eine Anfrage vorgelegt wird, DARF (MUST NOT) ein Cache eine gespeicherte Antwort nicht wiederverwenden, es sei denn:

  • Die vorgelegte effektive Anfrage-URI (Abschnitt 5.5 von [RFC7230]) und die der gespeicherten Antwort stimmen überein, und
  • die mit der gespeicherten Antwort verknüpfte Anfragemethode erlaubt ihre Verwendung für die vorgelegte Anfrage, und
  • die von der gespeicherten Antwort nominierten Auswahl-Header-Felder (falls vorhanden) stimmen mit den vorgelegten überein (siehe Abschnitt 4.1), und
  • die vorgelegte Anfrage enthält weder das no-cache-Pragma (Abschnitt 5.4) noch die no-cache-Cache-Direktive (Abschnitt 5.2.1), es sei denn, die gespeicherte Antwort wurde erfolgreich validiert (Abschnitt 4.3), und
  • die gespeicherte Antwort enthält nicht die no-cache-Cache-Direktive (Abschnitt 5.2.2.2), es sei denn, sie wurde erfolgreich validiert (Abschnitt 4.3), und
  • die gespeicherte Antwort ist entweder:
    • frisch (siehe Abschnitt 4.2), oder
    • darf veraltet bereitgestellt werden (siehe Abschnitt 4.2.4), oder
    • wurde erfolgreich validiert (siehe Abschnitt 4.3).

Beachten Sie, dass jede der oben aufgeführten Anforderungen durch eine Cache-Control-Erweiterung überschrieben werden kann; siehe Abschnitt 5.2.3.

Wenn eine gespeicherte Antwort verwendet wird, um eine Anfrage ohne Validierung zu erfüllen, MUSS (MUST) ein Cache ein Age-Header-Feld (Abschnitt 5.1) generieren und alle in der Antwort vorhandenen durch einen Wert ersetzen, der dem current_age der gespeicherten Antwort entspricht; siehe Abschnitt 4.2.3.

Ein Cache MUSS (MUST) Anfragen mit unsicheren Methoden (Abschnitt 4.2.1 von [RFC7231]) direkt an den Ursprungsserver durchleiten; d. h., ein Cache darf keine Antwort auf eine solche Anfrage generieren, bevor er die Anfrage weitergeleitet und eine entsprechende Antwort erhalten hat.

Beachten Sie außerdem, dass unsichere Anfragen bereits gespeicherte Antworten ungültig machen können; siehe Abschnitt 4.4.

Wenn mehr als eine geeignete Antwort gespeichert ist, MUSS (MUST) ein Cache die neueste Antwort verwenden (wie durch das Date-Header-Feld bestimmt). Er kann die Anfrage auch mit "Cache-Control: max-age=0" oder "Cache-Control: no-cache" weiterleiten, um zu klären, welche Antwort verwendet werden soll.

Ein Cache, der keine Uhr zur Verfügung hat, DARF NICHT (MUST NOT) gespeicherte Antworten verwenden, ohne sie bei jeder Verwendung erneut zu validieren.

🇮🇹 Italiano​

Quando viene presentata una richiesta, una cache NON DEVE (MUST NOT) riutilizzare una risposta memorizzata, a meno che:

  • L'URI di richiesta effettiva presentata (Sezione 5.5 di [RFC7230]) e quella della risposta memorizzata corrispondano, e
  • il metodo di richiesta associato alla risposta memorizzata ne consenta l'uso per la richiesta presentata, e
  • i campi di intestazione di selezione nominati dalla risposta memorizzata (se presenti) corrispondano a quelli presentati (vedere Sezione 4.1), e
  • la richiesta presentata non contenga il pragma no-cache (Sezione 5.4), né la direttiva di cache no-cache (Sezione 5.2.1), a meno che la risposta memorizzata non sia stata validata con successo (Sezione 4.3), e
  • la risposta memorizzata non contenga la direttiva di cache no-cache (Sezione 5.2.2.2), a meno che non sia stata validata con successo (Sezione 4.3), e
  • la risposta memorizzata sia:
    • fresca (vedere Sezione 4.2), o
    • autorizzata a essere servita obsoleta (vedere Sezione 4.2.4), o
    • validata con successo (vedere Sezione 4.3).

Si noti che uno qualsiasi dei requisiti elencati sopra può essere sostituito da un'estensione di controllo della cache; vedere Sezione 5.2.3.

Quando una risposta memorizzata viene utilizzata per soddisfare una richiesta senza validazione, una cache DEVE (MUST) generare un campo di intestazione Age (Sezione 5.1), sostituendo qualsiasi presente nella risposta con un valore uguale al current_age della risposta memorizzata; vedere Sezione 4.2.3.

Una cache DEVE (MUST) trasmettere direttamente le richieste con metodi non sicuri (Sezione 4.2.1 di [RFC7231]) al server di origine; cioè, una cache non è autorizzata a generare una risposta a tale richiesta prima di aver inoltrato la richiesta e ricevuto una risposta corrispondente.

Inoltre, si noti che le richieste non sicure potrebbero invalidare risposte già memorizzate; vedere Sezione 4.4.

Quando sono memorizzate più risposte adeguate, una cache DEVE (MUST) utilizzare la risposta più recente (come determinato dal campo di intestazione Date). Può anche inoltrare la richiesta con "Cache-Control: max-age=0" o "Cache-Control: no-cache" per disambiguare quale risposta utilizzare.

Una cache che non ha un orologio disponibile NON DEVE (MUST NOT) utilizzare risposte memorizzate senza rivalidarle ad ogni uso.

4.1. Calculating Secondary Keys with Vary (使用Vary计算次要键)​

🇬🇧 English​

When a cache receives a request that can be satisfied by a stored response that has a Vary header field (Section 7.1.4 of [RFC7231]), it MUST NOT use that response unless all of the selecting header fields nominated by the Vary header field match in both the original request (i.e., that associated with the stored response), and the presented request.

The selecting header fields from two requests are defined to match if and only if those in the first request can be transformed to those in the second request by applying any of the following:

  • adding or removing whitespace, where allowed in the header field's syntax
  • combining multiple header fields with the same field name (see Section 3.2 of [RFC7230])
  • normalizing both header field values in a way that is known to have identical semantics, according to the header field's specification (e.g., reordering field values when order is not significant; case-normalization, where values are defined to be case-insensitive)

If (after any normalization that might take place) a header field is absent from a request, it can only match another request if it is also absent there.

A Vary header field-value of "*" always fails to match.

The stored response with matching selecting header fields is known as the selected response.

If multiple selected responses are available (potentially including responses without a Vary header field), the cache will need to choose one to use. When a selecting header field has a known mechanism for doing so (e.g., qvalues on Accept and similar request header fields), that mechanism MAY be used to select preferred responses; of the remainder, the most recent response (as determined by the Date header field) is used, as per Section 4.

If no selected response is available, the cache cannot satisfy the presented request. Typically, it is forwarded to the origin server in a (possibly conditional; see Section 4.3) request.

🇨🇳 中文​

当缓存接收到可以由具有Vary头字段（[RFC7231] 的第7.1.4节）的存储响应满足的请求时，除非Vary头字段指定的所有选择头字段在原始请求（即与存储响应关联的请求）和呈现的请求中都匹配，否则缓存不得 (MUST NOT) 使用该响应。

当且仅当第一个请求中的选择头字段可以通过应用以下任何一项转换为第二个请求中的选择头字段时，两个请求的选择头字段才被定义为匹配:

  • 在头字段语法允许的地方添加或删除空白
  • 组合具有相同字段名称的多个头字段（见 [RFC7230] 的第3.2节）
  • 根据头字段的规范，以已知具有相同语义的方式规范化两个头字段值（例如，当顺序不重要时重新排序字段值; 在值定义为不区分大小写的情况下进行大小写规范化）

如果（在可能发生的任何规范化之后）请求中不存在头字段，则只有当另一个请求中也不存在该字段时才能匹配。

Vary头字段值为"*"总是无法匹配。

具有匹配选择头字段的存储响应称为选定响应。

如果有多个选定的响应可用（可能包括没有Vary头字段的响应），缓存将需要选择一个来使用。当选择头字段具有已知的机制（例如，Accept和类似请求头字段上的qvalues）时，该机制可以 (MAY) 用于选择首选响应; 在其余响应中，根据第4节，使用最新的响应（由Date头字段确定）。

如果没有可用的选定响应，缓存无法满足呈现的请求。通常，它会在（可能是条件的; 见第4.3节）请求中转发到源服务器。

🇯🇵 日本語​

キャッシュがVaryヘッダーフィールド（[RFC7231] のセクション7.1.4）を持つ保存されたレスポンスによって満たすことができるリクエストを受信した場合、Varyヘッダーフィールドによって指定されたすべての選択ヘッダーフィールドが、元のリクエスト（つまり、保存されたレスポンスに関連付けられたもの）と提示されたリクエストの両方で一致しない限り、そのレスポンスを使用してはならない (MUST NOT)。

2つのリクエストからの選択ヘッダーフィールドは、第1のリクエストのものが次のいずれかを適用することによって第2のリクエストのものに変換できる場合に限り、一致すると定義される:

  • ヘッダーフィールドの構文で許可されている場所で空白を追加または削除する
  • 同じフィールド名を持つ複数のヘッダーフィールドを結合する（[RFC7230] のセクション3.2参照）
  • ヘッダーフィールドの仕様に従って、同一のセマンティクスを持つことが知られている方法で両方のヘッダーフィールド値を正規化する（例えば、順序が重要でない場合にフィールド値を並べ替える; 値が大文字と小文字を区別しないと定義されている場合の大文字小文字の正規化）

（正規化が行われた後）リクエストにヘッダーフィールドが存在しない場合、別のリクエストにも存在しない場合にのみ一致できる。

Varyヘッダーフィールド値が"*"の場合、常に一致に失敗する。

一致する選択ヘッダーフィールドを持つ保存されたレスポンスは、選択されたレスポンスとして知られている。

複数の選択されたレスポンスが利用可能な場合（Varyヘッダーフィールドのないレスポンスを含む可能性がある）、キャッシュは使用するものを1つ選択する必要がある。選択ヘッダーフィールドに既知のメカニズム（例えば、Acceptおよび類似のリクエストヘッダーフィールドのqvalues）がある場合、そのメカニズムを使用して優先レスポンスを選択してもよい (MAY); 残りのうち、セクション4に従って、最新のレスポンス（Dateヘッダーフィールドによって決定される）が使用される。

選択されたレスポンスが利用できない場合、キャッシュは提示されたリクエストを満たすことができない。通常、（おそらく条件付き; セクション4.3参照）リクエストでオリジンサーバーに転送される。

🇫🇷 Français​

Lorsqu'un cache reçoit une requête qui peut être satisfaite par une réponse stockée contenant un champ d'en-tête Vary (Section 7.1.4 de [RFC7231]), il NE DOIT PAS (MUST NOT) utiliser cette réponse à moins que tous les champs d'en-tête de sélection désignés par le champ d'en-tête Vary ne correspondent à la fois dans la requête d'origine (c'est-à-dire celle associée à la réponse stockée) et dans la requête présentée.

Les champs d'en-tête de sélection de deux requêtes sont définis comme correspondant si et seulement si ceux de la première requête peuvent être transformés en ceux de la deuxième requête en appliquant l'un des éléments suivants :

  • ajout ou suppression d'espaces, lorsque cela est autorisé dans la syntaxe du champ d'en-tête
  • combinaison de plusieurs champs d'en-tête avec le même nom de champ (voir Section 3.2 de [RFC7230])
  • normalisation des deux valeurs de champ d'en-tête d'une manière connue pour avoir une sémantique identique, selon la spécification du champ d'en-tête (par exemple, réorganisation des valeurs de champ lorsque l'ordre n'est pas significatif ; normalisation de la casse, lorsque les valeurs sont définies comme insensibles à la casse)

Si (après toute normalisation qui pourrait avoir lieu) un champ d'en-tête est absent d'une requête, il ne peut correspondre à une autre requête que s'il en est également absent.

Une valeur de champ d'en-tête Vary de "*" échoue toujours à correspondre.

La réponse stockée avec des champs d'en-tête de sélection correspondants est connue comme la réponse sélectionnée.

Si plusieurs réponses sélectionnées sont disponibles (incluant potentiellement des réponses sans champ d'en-tête Vary), le cache devra en choisir une à utiliser. Lorsqu'un champ d'en-tête de sélection dispose d'un mécanisme connu pour ce faire (par exemple, qvalues sur Accept et champs d'en-tête de requête similaires), ce mécanisme PEUT (MAY) être utilisé pour sélectionner les réponses préférées ; parmi le reste, la réponse la plus récente (telle que déterminée par le champ d'en-tête Date) est utilisée, conformément à la Section 4.

Si aucune réponse sélectionnée n'est disponible, le cache ne peut pas satisfaire la requête présentée. En général, elle est transmise au serveur d'origine dans une requête (éventuellement conditionnelle ; voir Section 4.3).

🇩🇪 Deutsch​

Wenn ein Cache eine Anfrage erhält, die durch eine gespeicherte Antwort mit einem Vary-Header-Feld (Abschnitt 7.1.4 von [RFC7231]) erfüllt werden kann, DARF (MUST NOT) er diese Antwort nicht verwenden, es sei denn, alle vom Vary-Header-Feld nominierten Auswahl-Header-Felder stimmen sowohl in der ursprünglichen Anfrage (d. h. der mit der gespeicherten Antwort verknüpften) als auch in der vorgelegten Anfrage überein.

Die Auswahl-Header-Felder von zwei Anfragen sind definiert als übereinstimmend, wenn und nur wenn diejenigen in der ersten Anfrage durch Anwendung eines der folgenden in diejenigen in der zweiten Anfrage transformiert werden können:

  • Hinzufügen oder Entfernen von Leerzeichen, wo in der Syntax des Header-Felds erlaubt
  • Kombinieren mehrerer Header-Felder mit demselben Feldnamen (siehe Abschnitt 3.2 von [RFC7230])
  • Normalisieren beider Header-Feldwerte auf eine Weise, die bekanntermaßen identische Semantik hat, gemäß der Spezifikation des Header-Felds (z. B. Neuordnung von Feldwerten, wenn die Reihenfolge nicht signifikant ist; Groß-/Kleinschreibungsnormalisierung, wenn Werte als groß-/kleinschreibungsunabhängig definiert sind)

Wenn (nach jeder Normalisierung, die stattfinden könnte) ein Header-Feld in einer Anfrage fehlt, kann es nur mit einer anderen Anfrage übereinstimmen, wenn es dort ebenfalls fehlt.

Ein Vary-Header-Feldwert von "*" schlägt immer fehl zu übereinstimmen.

Die gespeicherte Antwort mit übereinstimmenden Auswahl-Header-Feldern ist als die ausgewählte Antwort bekannt.

Wenn mehrere ausgewählte Antworten verfügbar sind (potenziell einschließlich Antworten ohne Vary-Header-Feld), muss der Cache eine zur Verwendung auswählen. Wenn ein Auswahl-Header-Feld einen bekannten Mechanismus dafür hat (z. B. qvalues auf Accept und ähnlichen Anfrage-Header-Feldern), DARF (MAY) dieser Mechanismus verwendet werden, um bevorzugte Antworten auszuwählen; von den verbleibenden wird die neueste Antwort (wie durch das Date-Header-Feld bestimmt) verwendet, gemäß Abschnitt 4.

Wenn keine ausgewählte Antwort verfügbar ist, kann der Cache die vorgelegte Anfrage nicht erfüllen. Typischerweise wird sie in einer (möglicherweise bedingten; siehe Abschnitt 4.3) Anfrage an den Ursprungsserver weitergeleitet.

🇮🇹 Italiano​

Quando una cache riceve una richiesta che può essere soddisfatta da una risposta memorizzata che ha un campo di intestazione Vary (Sezione 7.1.4 di [RFC7231]), NON DEVE (MUST NOT) utilizzare quella risposta a meno che tutti i campi di intestazione di selezione nominati dal campo di intestazione Vary corrispondano sia nella richiesta originale (cioè quella associata alla risposta memorizzata) che nella richiesta presentata.

I campi di intestazione di selezione di due richieste sono definiti come corrispondenti se e solo se quelli nella prima richiesta possono essere trasformati in quelli nella seconda richiesta applicando uno dei seguenti:

  • aggiungendo o rimuovendo spazi bianchi, dove consentito nella sintassi del campo di intestazione
  • combinando più campi di intestazione con lo stesso nome di campo (vedere Sezione 3.2 di [RFC7230])
  • normalizzando entrambi i valori del campo di intestazione in un modo noto per avere semantica identica, secondo la specifica del campo di intestazione (ad esempio, riordinando i valori del campo quando l'ordine non è significativo; normalizzazione delle maiuscole/minuscole, dove i valori sono definiti come insensibili alle maiuscole/minuscole)

Se (dopo qualsiasi normalizzazione che potrebbe aver luogo) un campo di intestazione è assente da una richiesta, può corrispondere a un'altra richiesta solo se è assente anche lì.

Un valore del campo di intestazione Vary di "*" non riesce sempre a corrispondere.

La risposta memorizzata con campi di intestazione di selezione corrispondenti è nota come la risposta selezionata.

Se sono disponibili più risposte selezionate (potenzialmente includendo risposte senza un campo di intestazione Vary), la cache dovrà sceglierne una da utilizzare. Quando un campo di intestazione di selezione ha un meccanismo noto per farlo (ad esempio, qvalues su Accept e campi di intestazione di richiesta simili), quel meccanismo PUÒ (MAY) essere utilizzato per selezionare risposte preferite; del resto, viene utilizzata la risposta più recente (come determinato dal campo di intestazione Date), come per la Sezione 4.

Se non è disponibile alcuna risposta selezionata, la cache non può soddisfare la richiesta presentata. Tipicamente, viene inoltrata al server di origine in una richiesta (possibilmente condizionale; vedere Sezione 4.3).

📝 翻译说明 (Translation Notes)

  • Vary机制: 这是内容协商中的关键机制，各语言版本都保持了技术准确性
  • MUST NOT指令: 所有语言版本都严格遵循RFC 2119规范
  • 术语一致性: Secondary Keys (次要键), Selecting Header Fields (选择头字段) 等在所有语言中保持一致的翻译
に最終更新