4.3. Validation (验证)

🇬🇧 English

When a cache has one or more stored responses for a requested URI, but cannot serve any of them (e.g., because they are not fresh, or a request directive forbids it), it can use the conditional request mechanism [RFC7232] in the forwarded request to give the origin server an opportunity to select a valid stored response to be used, updating the stored metadata in the process, or to replace the stored response(s) with a new response. This process is known as "validating" or "revalidating" the stored response.

🇨🇳 中文

当缓存对于请求的URI具有一个或多个存储的响应，但无法提供其中任何一个时（例如，因为它们不新鲜，或请求指令禁止），它可以在转发的请求中使用条件请求机制 [RFC7232]，以便让源服务器有机会选择要使用的有效存储响应，在此过程中更新存储的元数据，或者用新响应替换存储的响应。此过程称为"验证"或"重新验证"存储的响应。

🇯🇵 日本語

キャッシュが要求されたURIに対して1つ以上の保存されたレスポンスを持っているが、それらのいずれも提供できない場合（例えば、新鮮ではない、またはリクエストディレクティブが禁止しているため）、転送されたリクエストで条件付きリクエストメカニズム [RFC7232] を使用して、オリジンサーバーに使用する有効な保存されたレスポンスを選択する機会を与えることができる。このプロセスで保存されたメタデータを更新するか、保存されたレスポンスを新しいレスポンスで置き換える。このプロセスは、保存されたレスポンスの「検証」または「再検証」と呼ばれる。

🇫🇷 Français

Lorsqu'un cache possède une ou plusieurs réponses stockées pour un URI demandé, mais ne peut en servir aucune (par exemple, parce qu'elles ne sont pas fraîches, ou qu'une directive de requête l'interdit), il peut utiliser le mécanisme de requête conditionnelle [RFC7232] dans la requête transmise pour donner au serveur d'origine l'opportunité de sélectionner une réponse stockée valide à utiliser, en mettant à jour les métadonnées stockées dans le processus, ou de remplacer la ou les réponses stockées par une nouvelle réponse. Ce processus est connu sous le nom de "validation" ou "revalidation" de la réponse stockée.

🇩🇪 Deutsch

Wenn ein Cache eine oder mehrere gespeicherte Antworten für einen angeforderten URI hat, aber keine davon bereitstellen kann (z. B., weil sie nicht frisch sind oder eine Anfragedirektive dies verbietet), kann er den Mechanismus für bedingte Anfragen [RFC7232] in der weitergeleiteten Anfrage verwenden, um dem Ursprungsserver die Möglichkeit zu geben, eine gültige gespeicherte Antwort zur Verwendung auszuwählen, wobei die gespeicherten Metadaten im Prozess aktualisiert werden, oder die gespeicherte(n) Antwort(en) durch eine neue Antwort zu ersetzen. Dieser Prozess wird als "Validierung" oder "Revalidierung" der gespeicherten Antwort bezeichnet.

🇮🇹 Italiano

Quando una cache ha una o più risposte memorizzate per un URI richiesto, ma non può servire nessuna di esse (ad esempio, perché non sono fresche, o una direttiva di richiesta lo vieta), può utilizzare il meccanismo di richiesta condizionale [RFC7232] nella richiesta inoltrata per dare al server di origine l'opportunità di selezionare una risposta memorizzata valida da utilizzare, aggiornando i metadati memorizzati nel processo, o di sostituire la o le risposte memorizzate con una nuova risposta. Questo processo è noto come "validazione" o "rivalidazione" della risposta memorizzata.

---

4.3.1. Sending a Validation Request (发送验证请求)

🇬🇧 English

When generating a conditional request for validation, a cache either starts with a request it is attempting to satisfy or (if it is initiating the request independently) synthesizes a request using a stored response by copying the method, target URI, and relevant request header fields.

It then updates that request with one or more precondition header fields. These contain validator metadata (Section 2.3 of [RFC7232]) taken from the stored response(s) being validated. Typically, this will include the stored response's Last-Modified and/or ETag field values.

The cache can then send the conditional request to the origin server (or, potentially, a downstream cache listed in a Via header field).

🇨🇳 中文

当生成用于验证的条件请求时，缓存要么从其尝试满足的请求开始，要么（如果它独立发起请求）通过复制方法、目标URI和相关请求头字段，使用存储的响应合成请求。

然后，它使用一个或多个前提条件头字段更新该请求。这些字段包含从正在验证的存储响应中获取的验证器元数据（[RFC7232] 的第2.3节）。通常，这将包括存储响应的Last-Modified和/或ETag字段值。

然后，缓存可以将条件请求发送到源服务器（或者，可能发送到Via头字段中列出的下游缓存）。

🇯🇵 日本語

検証用の条件付きリクエストを生成する場合、キャッシュは、満たそうとしているリクエストから開始するか、（独立してリクエストを開始する場合）メソッド、ターゲットURI、および関連するリクエストヘッダーフィールドをコピーして、保存されたレスポンスを使用してリクエストを合成する。

次に、1つ以上の前提条件ヘッダーフィールドでそのリクエストを更新する。これらには、検証される保存されたレスポンスから取得されたバリデータメタデータ（[RFC7232] のセクション2.3）が含まれる。通常、これには保存されたレスポンスのLast-ModifiedおよびETagフィールド値が含まれる。

次に、キャッシュは条件付きリクエストをオリジンサーバー（または、Viaヘッダーフィールドにリストされている下流のキャッシュ）に送信できる。

🇫🇷 Français

Lors de la génération d'une requête conditionnelle pour validation, un cache commence soit avec une requête qu'il tente de satisfaire, soit (s'il initie la requête de manière indépendante) synthétise une requête en utilisant une réponse stockée en copiant la méthode, l'URI cible et les champs d'en-tête de requête pertinents.

Il met ensuite à jour cette requête avec un ou plusieurs champs d'en-tête de précondition. Ceux-ci contiennent des métadonnées de validateur (Section 2.3 de [RFC7232]) extraites de la ou des réponses stockées en cours de validation. En général, cela inclura les valeurs des champs Last-Modified et/ou ETag de la réponse stockée.

Le cache peut ensuite envoyer la requête conditionnelle au serveur d'origine (ou, potentiellement, à un cache en aval répertorié dans un champ d'en-tête Via).

🇩🇪 Deutsch

Bei der Generierung einer bedingten Anfrage zur Validierung beginnt ein Cache entweder mit einer Anfrage, die er zu erfüllen versucht, oder (wenn er die Anfrage unabhängig initiiert) synthetisiert eine Anfrage unter Verwendung einer gespeicherten Antwort, indem er die Methode, den Ziel-URI und relevante Anfrage-Header-Felder kopiert.

Anschließend aktualisiert er diese Anfrage mit einem oder mehreren Vorbedingung-Header-Feldern. Diese enthalten Validator-Metadaten (Abschnitt 2.3 von [RFC7232]), die aus den zu validierenden gespeicherten Antwort(en) entnommen wurden. Typischerweise umfasst dies die Last-Modified- und/oder ETag-Feldwerte der gespeicherten Antwort.

Der Cache kann dann die bedingte Anfrage an den Ursprungsserver (oder möglicherweise an einen nachgelagerten Cache, der in einem Via-Header-Feld aufgeführt ist) senden.

🇮🇹 Italiano

Quando genera una richiesta condizionale per la validazione, una cache inizia con una richiesta che sta tentando di soddisfare oppure (se sta avviando la richiesta in modo indipendente) sintetizza una richiesta utilizzando una risposta memorizzata copiando il metodo, l'URI di destinazione e i campi di intestazione di richiesta pertinenti.

Successivamente aggiorna quella richiesta con uno o più campi di intestazione di precondizione. Questi contengono metadati di validatore (Sezione 2.3 di [RFC7232]) presi dalla o dalle risposte memorizzate in fase di validazione. Tipicamente, questo includerà i valori dei campi Last-Modified e/o ETag della risposta memorizzata.

La cache può quindi inviare la richiesta condizionale al server di origine (o, potenzialmente, a una cache a valle elencata in un campo di intestazione Via).

---

4.3.2. Handling a Received Validation Request (处理接收到的验证请求)

🇬🇧 English

Each client in the request chain may have its own cache, so it is common for a cache at an intermediary to receive conditional requests from other (outbound) caches. Likewise, some clients might have clock skew or other issues that lead them to generate conditional requests without understanding them, or such requests might be generated by an implementation that uses HTTP underlying libraries.

This means that serving a 304 (Not Modified) or 412 (Precondition Failed) response to a conditional request cannot be assumed to imply that the client understands such responses, or that it has a cached copy (even if it does have one, it might have been removed).

When a cache receives a request that includes a validator field (such as an If-None-Match header field), it MUST NOT return a 304 (Not Modified) response unless it is certain that the stored response that is the subject of the conditional request is the most recent validation response received from upstream. In particular, intermediaries need to verify that the stored response's validators (ETag and Last-Modified field values, if present) are byte-for-byte identical to those presented in the conditional request.

Note that a cache is not required to perform such a check when it does not have a stored response (i.e., it is performing "on-demand" caching).

A cache MUST NOT send a 304 (Not Modified) response in reply to a request that contains either an If-None-Match or If-Modified-Since precondition header field whose condition evaluates to false, because the client would not be able to construct a valid response from the cache's stored response.

Instead, a cache that receives a conditional request, and that has a stored response that is suitable for serving in reply, will either:

• send a 304 (Not Modified) response if the stored response is fresh (Section 4.2), or if it has been successfully validated (Section 4.3), or
• forward the request towards the origin server with its own conditional request that attempts to validate the stored response.

In the latter case, the cache will include a validator in the forwarded request. The forwarded request MUST use the most recent set of validators associated with the stored response.

🇨🇳 中文

请求链中的每个客户端可能都有自己的缓存，因此中间层的缓存从其他（出站）缓存接收条件请求是很常见的。同样，某些客户端可能存在时钟偏差或其他问题，导致它们在不理解的情况下生成条件请求，或者此类请求可能由使用HTTP底层库的实现生成。

这意味着，对条件请求提供304（未修改）或412（前提条件失败）响应，不能假定客户端理解此类响应，或者它具有缓存副本（即使它确实有，也可能已被删除）。

当缓存接收到包含验证器字段（如If-None-Match头字段）的请求时，除非它确定作为条件请求主题的存储响应是从上游接收的最新验证响应，否则它不得 (MUST NOT) 返回304（未修改）响应。特别是，中间层需要验证存储响应的验证器（如果存在ETag和Last-Modified字段值）是否与条件请求中呈现的验证器逐字节相同。

请注意，当缓存没有存储响应时（即，它正在执行"按需"缓存），不需要执行此类检查。

缓存不得 (MUST NOT) 对包含If-None-Match或If-Modified-Since前提条件头字段且其条件评估为false的请求发送304（未修改）响应，因为客户端将无法从缓存的存储响应构造有效响应。

相反，接收到条件请求并且具有适合用于响应的存储响应的缓存将:

• 如果存储的响应是新鲜的（第4.2节），或者已成功验证（第4.3节），则发送304（未修改）响应，或
• 使用自己的条件请求将请求转发到源服务器，该条件请求尝试验证存储的响应。

在后一种情况下，缓存将在转发的请求中包含验证器。转发的请求必须 (MUST) 使用与存储响应关联的最新验证器集。

🇯🇵 日本語

リクエストチェーン内の各クライアントは独自のキャッシュを持つ可能性があるため、中間層のキャッシュが他の（アウトバウンド）キャッシュから条件付きリクエストを受信することは一般的である。同様に、一部のクライアントには時計のずれやその他の問題があり、それらを理解せずに条件付きリクエストを生成する可能性があるか、またはそのようなリクエストはHTTP基盤ライブラリを使用する実装によって生成される可能性がある。

これは、条件付きリクエストに対して304（Not Modified）または412（Precondition Failed）レスポンスを提供することが、クライアントがそのようなレスポンスを理解していること、またはキャッシュされたコピーを持っていること（たとえ持っていても、削除された可能性がある）を意味すると想定できないことを意味する。

キャッシュがバリデータフィールド（If-None-Matchヘッダーフィールドなど）を含むリクエストを受信した場合、条件付きリクエストの対象である保存されたレスポンスが上流から受信した最新の検証レスポンスであることが確実でない限り、304（Not Modified）レスポンスを返してはならない (MUST NOT)。特に、中間層は、保存されたレスポンスのバリデータ（存在する場合、ETagおよびLast-Modifiedフィールド値）が条件付きリクエストで提示されたものとバイト単位で同一であることを検証する必要がある。

キャッシュが保存されたレスポンスを持たない場合（つまり、「オンデマンド」キャッシングを実行している場合）、そのようなチェックを実行する必要はないことに注意すること。

キャッシュは、If-None-MatchまたはIf-Modified-Since前提条件ヘッダーフィールドを含み、その条件がfalseと評価されるリクエストに対して304（Not Modified）レスポンスを送信してはならない (MUST NOT)。これは、クライアントがキャッシュの保存されたレスポンスから有効なレスポンスを構築できないためである。

代わりに、条件付きリクエストを受信し、応答に使用するのに適した保存されたレスポンスを持つキャッシュは、次のいずれかを実行する:

• 保存されたレスポンスが新鮮である（セクション4.2）場合、または正常に検証された（セクション4.3）場合、304（Not Modified）レスポンスを送信する、または
• 保存されたレスポンスを検証しようとする独自の条件付きリクエストでリクエストをオリジンサーバーに転送する。

後者の場合、キャッシュは転送されたリクエストにバリデータを含める。転送されたリクエストは、保存されたレスポンスに関連付けられた最新のバリデータセットを使用しなければならない (MUST)。

🇫🇷 Français

Chaque client dans la chaîne de requêtes peut avoir son propre cache, il est donc courant qu'un cache à un intermédiaire reçoive des requêtes conditionnelles d'autres caches (sortants). De même, certains clients peuvent avoir une désynchronisation d'horloge ou d'autres problèmes qui les amènent à générer des requêtes conditionnelles sans les comprendre, ou de telles requêtes peuvent être générées par une implémentation qui utilise des bibliothèques HTTP sous-jacentes.

Cela signifie que servir une réponse 304 (Not Modified) ou 412 (Precondition Failed) à une requête conditionnelle ne peut pas être supposé impliquer que le client comprend de telles réponses, ou qu'il a une copie en cache (même s'il en a une, elle pourrait avoir été supprimée).

Lorsqu'un cache reçoit une requête qui inclut un champ de validateur (tel qu'un champ d'en-tête If-None-Match), il NE DOIT PAS (MUST NOT) renvoyer une réponse 304 (Not Modified) à moins qu'il ne soit certain que la réponse stockée qui est le sujet de la requête conditionnelle est la réponse de validation la plus récente reçue de l'amont. En particulier, les intermédiaires doivent vérifier que les validateurs de la réponse stockée (valeurs des champs ETag et Last-Modified, si présents) sont identiques octet par octet à ceux présentés dans la requête conditionnelle.

Notez qu'un cache n'est pas tenu d'effectuer une telle vérification lorsqu'il n'a pas de réponse stockée (c'est-à-dire qu'il effectue une mise en cache "à la demande").

Un cache NE DOIT PAS (MUST NOT) envoyer une réponse 304 (Not Modified) en réponse à une requête qui contient un champ d'en-tête de précondition If-None-Match ou If-Modified-Since dont la condition s'évalue à faux, car le client ne serait pas en mesure de construire une réponse valide à partir de la réponse stockée du cache.

Au lieu de cela, un cache qui reçoit une requête conditionnelle et qui a une réponse stockée qui convient pour servir en réponse, soit :

• enverra une réponse 304 (Not Modified) si la réponse stockée est fraîche (Section 4.2), ou si elle a été validée avec succès (Section 4.3), ou
• transmettra la requête vers le serveur d'origine avec sa propre requête conditionnelle qui tente de valider la réponse stockée.

Dans ce dernier cas, le cache inclura un validateur dans la requête transmise. La requête transmise DOIT (MUST) utiliser l'ensemble le plus récent de validateurs associés à la réponse stockée.

🇩🇪 Deutsch

Jeder Client in der Anfragekette kann seinen eigenen Cache haben, daher ist es üblich, dass ein Cache bei einem Vermittler bedingte Anfragen von anderen (ausgehenden) Caches erhält. Ebenso können einige Clients Uhrenabweichungen oder andere Probleme haben, die dazu führen, dass sie bedingte Anfragen generieren, ohne sie zu verstehen, oder solche Anfragen können von einer Implementierung generiert werden, die zugrunde liegende HTTP-Bibliotheken verwendet.

Dies bedeutet, dass das Bereitstellen einer 304 (Not Modified)- oder 412 (Precondition Failed)-Antwort auf eine bedingte Anfrage nicht implizieren kann, dass der Client solche Antworten versteht oder dass er eine zwischengespeicherte Kopie hat (selbst wenn er eine hat, könnte sie entfernt worden sein).

Wenn ein Cache eine Anfrage erhält, die ein Validator-Feld enthält (z. B. ein If-None-Match-Header-Feld), DARF er NICHT (MUST NOT) eine 304 (Not Modified)-Antwort zurückgeben, es sei denn, er ist sicher, dass die gespeicherte Antwort, die Gegenstand der bedingten Anfrage ist, die neueste Validierungsantwort ist, die von vorgelagerten Stellen empfangen wurde. Insbesondere müssen Vermittler überprüfen, ob die Validatoren der gespeicherten Antwort (ETag- und Last-Modified-Feldwerte, falls vorhanden) Byte für Byte mit denen in der bedingten Anfrage identisch sind.

Beachten Sie, dass ein Cache eine solche Überprüfung nicht durchführen muss, wenn er keine gespeicherte Antwort hat (d. h., er führt "On-Demand"-Caching durch).

Ein Cache DARF NICHT (MUST NOT) eine 304 (Not Modified)-Antwort als Antwort auf eine Anfrage senden, die entweder ein If-None-Match- oder If-Modified-Since-Vorbedingung-Header-Feld enthält, dessen Bedingung als falsch bewertet wird, da der Client keine gültige Antwort aus der gespeicherten Antwort des Caches konstruieren könnte.

Stattdessen wird ein Cache, der eine bedingte Anfrage erhält und eine gespeicherte Antwort hat, die zur Bereitstellung als Antwort geeignet ist, entweder:

• eine 304 (Not Modified)-Antwort senden, wenn die gespeicherte Antwort frisch ist (Abschnitt 4.2) oder erfolgreich validiert wurde (Abschnitt 4.3), oder
• die Anfrage mit seiner eigenen bedingten Anfrage, die versucht, die gespeicherte Antwort zu validieren, an den Ursprungsserver weiterleiten.

Im letzteren Fall wird der Cache einen Validator in die weitergeleitete Anfrage aufnehmen. Die weitergeleitete Anfrage MUSS (MUST) den neuesten Satz von Validatoren verwenden, der mit der gespeicherten Antwort verknüpft ist.

🇮🇹 Italiano

Ogni client nella catena di richieste può avere la propria cache, quindi è comune che una cache presso un intermediario riceva richieste condizionali da altre cache (in uscita). Allo stesso modo, alcuni client potrebbero avere disallineamenti dell'orologio o altri problemi che li portano a generare richieste condizionali senza comprenderle, o tali richieste potrebbero essere generate da un'implementazione che utilizza librerie HTTP sottostanti.

Ciò significa che servire una risposta 304 (Not Modified) o 412 (Precondition Failed) a una richiesta condizionale non può essere assunto che implichi che il client comprenda tali risposte, o che abbia una copia in cache (anche se ne ha una, potrebbe essere stata rimossa).

Quando una cache riceve una richiesta che include un campo validatore (come un campo di intestazione If-None-Match), NON DEVE (MUST NOT) restituire una risposta 304 (Not Modified) a meno che non sia certa che la risposta memorizzata che è l'oggetto della richiesta condizionale sia la risposta di validazione più recente ricevuta da monte. In particolare, gli intermediari devono verificare che i validatori della risposta memorizzata (valori dei campi ETag e Last-Modified, se presenti) siano identici byte per byte a quelli presentati nella richiesta condizionale.

Si noti che una cache non è tenuta a eseguire tale controllo quando non ha una risposta memorizzata (cioè, sta eseguendo il caching "on-demand").

Una cache NON DEVE (MUST NOT) inviare una risposta 304 (Not Modified) in risposta a una richiesta che contiene un campo di intestazione di precondizione If-None-Match o If-Modified-Since la cui condizione viene valutata come falsa, poiché il client non sarebbe in grado di costruire una risposta valida dalla risposta memorizzata della cache.

Invece, una cache che riceve una richiesta condizionale e che ha una risposta memorizzata adatta per essere servita in risposta, farà una delle seguenti:

• invierà una risposta 304 (Not Modified) se la risposta memorizzata è fresca (Sezione 4.2), o se è stata validata con successo (Sezione 4.3), o
• inoltrerà la richiesta verso il server di origine con la propria richiesta condizionale che tenta di validare la risposta memorizzata.

In quest'ultimo caso, la cache includerà un validatore nella richiesta inoltrata. La richiesta inoltrata DEVE (MUST) utilizzare l'insieme più recente di validatori associati alla risposta memorizzata.

---

📝 翻译说明 (Translation Notes)

• 4.3 核心概念: Validation是HTTP缓存机制中最精巧的部分，涉及If-None-Match、If-Modified-Since等条件请求头
• 4.3.2 关键逻辑: 304 Not Modified响应的生成条件在所有语言版本中都保持了法律级的精确性
• 验证器 (Validator): ETag和Last-Modified在所有语言中保持英文原文，确保技术一致性
• 字节级比较: "byte-for-byte identical"的严格要求在所有语言版本中得到了准确传达