2. Validators (Validateurs)

Cette spécification définit deux formes de métadonnées couramment utilisées pour observer l'état des ressources et tester les préconditions: les dates de modification (Section 2.2) et les balises d'entité opaques (Section 2.3). Des métadonnées supplémentaires reflétant l'état des ressources ont été définies par diverses extensions de HTTP, telles que Web Distributed Authoring and Versioning (WebDAV, [RFC4918]), qui dépassent le cadre de cette spécification. Une valeur de métadonnées de ressource est appelée "validateur" (validator) lorsqu'elle est utilisée dans une précondition.

2.1. Weak versus Strong (Faible versus fort)

Les validateurs existent en deux variantes: forts ou faibles. Les validateurs faibles sont faciles à générer mais sont beaucoup moins utiles pour les comparaisons. Les validateurs forts sont idéaux pour les comparaisons mais peuvent être très difficiles (et parfois impossibles) à générer efficacement. Plutôt que d'imposer que toutes les formes de ressources adhèrent à la même force de validateur, HTTP expose le type de validateur utilisé et impose des restrictions sur le moment où les validateurs faibles peuvent être utilisés comme préconditions.

Un "validateur fort" (strong validator) est une métadonnée de représentation qui change de valeur chaque fois qu'un changement se produit dans les données de représentation qui serait observable dans le corps de la charge utile d'une réponse 200 (OK) à GET.

Un validateur fort peut changer pour des raisons autres qu'un changement des données de représentation, par exemple lorsqu'une partie sémantiquement significative des métadonnées de représentation est modifiée (par exemple Content-Type), mais il est dans l'intérêt du serveur d'origine de ne modifier la valeur que lorsqu'il est nécessaire d'invalider les réponses stockées détenues par les caches distants et les outils de création.

Les entrées de cache peuvent persister pendant des périodes arbitrairement longues, indépendamment des temps d'expiration. Ainsi, un cache peut tenter de valider une entrée en utilisant un validateur qu'il a obtenu dans un passé lointain. Un validateur fort est unique à travers toutes les versions de toutes les représentations associées à une ressource particulière au fil du temps. Cependant, il n'y a pas d'implication d'unicité entre les représentations de différentes ressources (c'est-à-dire que le même validateur fort peut être utilisé pour les représentations de plusieurs ressources en même temps et n'implique pas que ces représentations sont équivalentes).

En revanche, un "validateur faible" (weak validator) est une métadonnée de représentation qui peut ne pas changer pour chaque changement des données de représentation. Cette faiblesse peut être due à des limitations dans la façon dont la valeur est calculée, telles que la résolution de l'horloge, une incapacité à garantir l'unicité pour toutes les représentations possibles de la ressource, ou un désir du propriétaire de la ressource de regrouper les représentations par un ensemble d'équivalence autodéterminé plutôt que par des séquences uniques de données. Un serveur d'origine DEVRAIT changer une balise d'entité faible chaque fois qu'il considère que les représentations antérieures sont inacceptables comme substitut de la représentation actuelle. En d'autres termes, une balise d'entité faible devrait changer chaque fois que le serveur d'origine veut que les caches invalident les anciennes réponses.

Les validateurs forts sont utilisables pour toutes les requêtes conditionnelles, y compris la validation du cache, les plages de contenu partiel et l'évitement de "mise à jour perdue". Les validateurs faibles ne sont utilisables que lorsque le client ne nécessite pas d'égalité exacte avec les données de représentation précédemment obtenues, par exemple lors de la validation d'une entrée de cache ou de la limitation d'un parcours Web aux changements récents.

2.2. Last-Modified (Dernière modification)

Le champ d'en-tête Last-Modified dans une réponse fournit un horodatage indiquant la date et l'heure auxquelles le serveur d'origine estime que la représentation sélectionnée a été modifiée pour la dernière fois, tel que déterminé à la conclusion du traitement de la requête.

Last-Modified = HTTP-date

Exemple d'utilisation:

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

2.2.1. Generation (Génération)

Un serveur d'origine DEVRAIT envoyer Last-Modified pour toute représentation sélectionnée pour laquelle une date de dernière modification peut être déterminée de manière raisonnable et cohérente, car son utilisation dans les requêtes conditionnelles et l'évaluation de la fraîcheur du cache ([RFC7234]) entraîne une réduction substantielle du trafic HTTP sur Internet et peut être un facteur important dans l'amélioration de l'évolutivité et de la fiabilité du service.

Un serveur d'origine DEVRAIT obtenir la valeur Last-Modified de la représentation aussi près que possible du moment où il génère la valeur du champ Date pour sa réponse. Cela permet à un destinataire de faire une évaluation précise du temps de modification de la représentation, en particulier si la représentation change près du moment où la réponse est générée.

Un serveur d'origine avec une horloge NE DOIT PAS envoyer une date Last-Modified qui est postérieure au temps d'origine du message du serveur (Date). Si le temps de dernière modification est dérivé de métadonnées spécifiques à l'implémentation qui s'évalue à un moment dans le futur, selon l'horloge du serveur d'origine, alors le serveur d'origine DOIT remplacer cette valeur par la date d'origine du message. Cela empêche une date de modification future d'avoir un impact négatif sur la validation du cache.

2.2.2. Comparison (Comparaison)

Un temps Last-Modified, lorsqu'il est utilisé comme validateur dans une requête, est implicitement faible sauf s'il est possible de déduire qu'il est fort, en utilisant des règles spécifiques définies dans la spécification.

2.3. ETag

Le champ d'en-tête ETag dans une réponse fournit la balise d'entité actuelle pour la représentation sélectionnée, telle que déterminée à la conclusion du traitement de la requête. Une balise d'entité est un validateur opaque pour différencier plusieurs représentations de la même ressource, que ces multiples représentations soient dues à des changements d'état de la ressource au fil du temps, à une négociation de contenu entraînant plusieurs représentations valides en même temps, ou aux deux.

ETag = entity-tag

entity-tag = [ weak ] opaque-tag
weak = %x57.2F ; "W/", sensible à la casse
opaque-tag = DQUOTE *etagc DQUOTE
etagc = %x21 / %x23-7E / obs-text

Exemples:

ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""

Une balise d'entité peut être un validateur faible ou fort, le fort étant par défaut. Si un serveur d'origine fournit une balise d'entité pour une représentation et que la génération de cette balise d'entité ne satisfait pas toutes les caractéristiques d'un validateur fort (Section 2.1), alors le serveur d'origine DOIT marquer la balise d'entité comme faible en préfixant sa valeur opaque avec W/ (sensible à la casse).

2.3.1. Generation (Génération)

Le principe derrière les balises d'entité est que seul l'auteur du service connaît suffisamment bien l'implémentation d'une ressource pour sélectionner le mécanisme de validation le plus précis et le plus efficace pour cette ressource, et que tout tel mécanisme peut être mappé à une simple séquence d'octets pour une comparaison facile. Étant donné que la valeur est opaque, il n'est pas nécessaire que le client soit conscient de la façon dont chaque balise d'entité est construite.

Un serveur d'origine DEVRAIT envoyer un ETag pour toute représentation sélectionnée pour laquelle la détection des changements peut être déterminée de manière raisonnable et cohérente, car l'utilisation de la balise d'entité dans les requêtes conditionnelles et l'évaluation de la fraîcheur du cache ([RFC7234]) peut entraîner une réduction substantielle du trafic réseau HTTP et peut être un facteur important dans l'amélioration de l'évolutivité et de la fiabilité du service.

2.3.2. Comparison (Comparaison)

Il existe deux fonctions de comparaison de balises d'entité, selon que le contexte de comparaison permet ou non l'utilisation de validateurs faibles:

• Comparaison forte (Strong comparison): deux balises d'entité sont équivalentes si les deux ne sont pas faibles et que leurs balises opaques correspondent caractère par caractère.
• Comparaison faible (Weak comparison): deux balises d'entité sont équivalentes si leurs balises opaques correspondent caractère par caractère, que l'une ou les deux soient marquées comme "faibles".

L'exemple ci-dessous montre les résultats pour un ensemble de paires de balises d'entité:

ETag 1	ETag 2	Comparaison forte	Comparaison faible
W/"1"	W/"1"	pas de correspondance	correspondance
W/"1"	W/"2"	pas de correspondance	pas de correspondance
W/"1"	"1"	pas de correspondance	correspondance
"1"	"1"	correspondance	correspondance

2.4. When to Use Entity-Tags and Last-Modified Dates (Quand utiliser les balises d'entité et les dates de dernière modification)

Dans les réponses 200 (OK) à GET ou HEAD, un serveur d'origine:

• DEVRAIT envoyer un validateur de balise d'entité sauf s'il n'est pas possible d'en générer un.
• PEUT envoyer une balise d'entité faible au lieu d'une balise d'entité forte, si les considérations de performance supportent l'utilisation de balises d'entité faibles, ou s'il est impossible d'envoyer une balise d'entité forte.
• DEVRAIT envoyer une valeur Last-Modified s'il est possible d'en envoyer une.

En d'autres termes, le comportement préféré pour un serveur d'origine est d'envoyer à la fois une balise d'entité forte et une valeur Last-Modified dans les réponses réussies à une requête de récupération.

Un client:

• DOIT envoyer cette balise d'entité dans toute requête de validation de cache (en utilisant If-Match ou If-None-Match) si une balise d'entité a été fournie par le serveur d'origine.
• DEVRAIT envoyer la valeur Last-Modified dans les requêtes de validation de cache non-sous-plage (en utilisant If-Modified-Since) si seule une valeur Last-Modified a été fournie par le serveur d'origine.
• DEVRAIT envoyer les deux validateurs dans les requêtes de validation de cache si à la fois une balise d'entité et une valeur Last-Modified ont été fournies par le serveur d'origine. Cela permet aux caches HTTP/1.0 et HTTP/1.1 de répondre de manière appropriée.