3. Precondition Header Fields (Champs d'en-tête de précondition)

Cette section définit la syntaxe et la sémantique des champs d'en-tête HTTP/1.1 pour appliquer des préconditions aux requêtes. La Section 5 définit quand les préconditions sont appliquées. La Section 6 définit l'ordre d'évaluation lorsque plusieurs préconditions sont présentes.

3.1. If-Match

Le champ d'en-tête If-Match rend la méthode de requête conditionnelle au fait que le serveur d'origine destinataire dispose d'au moins une représentation actuelle de la ressource cible, lorsque la valeur du champ est "*", ou dispose d'une représentation actuelle de la ressource cible ayant une balise d'entité correspondant à un membre de la liste de balises d'entité fournie dans la valeur du champ.

Un serveur d'origine DOIT utiliser la fonction de comparaison forte lors de la comparaison des balises d'entité pour If-Match (Section 2.3.2), car le client a l'intention que cette précondition empêche l'application de la méthode s'il y a eu des changements dans les données de représentation.

If-Match = "*" / 1#entity-tag

Exemples:

If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *

If-Match est le plus souvent utilisé avec les méthodes modifiant l'état (par exemple POST, PUT, DELETE) pour éviter les écrasements accidentels lorsque plusieurs agents utilisateurs peuvent agir en parallèle sur la même ressource (c'est-à-dire pour éviter le problème de "mise à jour perdue"). Il peut également être utilisé avec des méthodes sûres pour abandonner une requête si la représentation sélectionnée ne correspond pas à une représentation déjà stockée (ou partiellement stockée) d'une requête antérieure.

Un serveur d'origine qui reçoit un champ d'en-tête If-Match DOIT évaluer la condition avant d'exécuter la méthode (Section 5). Si la valeur du champ est "*", la condition est false si le serveur d'origine n'a pas de représentation actuelle pour la ressource cible. Si la valeur du champ est une liste de balises d'entité, la condition est false si aucune des balises listées ne correspond à la balise d'entité de la représentation sélectionnée.

Un serveur d'origine NE DOIT PAS exécuter la méthode demandée si une condition If-Match reçue est évaluée à false; au lieu de cela, le serveur d'origine DOIT répondre soit a) par le code d'état 412 (Precondition Failed), soit b) par l'un des codes d'état 2xx (Successful) si le serveur d'origine a vérifié qu'un changement d'état est demandé et que l'état final est déjà reflété dans l'état actuel de la ressource cible.

Le champ d'en-tête If-Match peut être ignoré par les caches et les intermédiaires car il n'est pas applicable à une réponse stockée.

3.2. If-None-Match

Le champ d'en-tête If-None-Match rend la méthode de requête conditionnelle au fait qu'un cache ou serveur d'origine destinataire n'a aucune représentation actuelle de la ressource cible, lorsque la valeur du champ est "*", ou a une représentation sélectionnée avec une balise d'entité qui ne correspond à aucune de celles listées dans la valeur du champ.

Un destinataire DOIT utiliser la fonction de comparaison faible lors de la comparaison des balises d'entité pour If-None-Match (Section 2.3.2), car les balises d'entité faibles peuvent être utilisées pour la validation du cache même s'il y a eu des changements dans les données de représentation.

If-None-Match = "*" / 1#entity-tag

Exemples:

If-None-Match: "xyzzy"
If-None-Match: W/"xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
If-None-Match: *

If-None-Match est principalement utilisé dans les requêtes GET conditionnelles pour permettre des mises à jour efficaces des informations en cache avec un minimum de surcharge transactionnelle. Lorsqu'un client souhaite mettre à jour une ou plusieurs réponses stockées ayant des balises d'entité, le client DEVRAIT générer un champ d'en-tête If-None-Match contenant une liste de ces balises d'entité lors de l'émission d'une requête GET; cela permet aux serveurs destinataires d'envoyer une réponse 304 (Not Modified) pour indiquer quand l'une de ces réponses stockées correspond à la représentation sélectionnée.

If-None-Match peut également être utilisé avec une valeur de "*" pour empêcher une méthode de requête non sûre (par exemple PUT) de modifier par inadvertance une représentation existante de la ressource cible lorsque le client estime que la ressource n'a pas de représentation actuelle.

Un serveur d'origine qui reçoit un champ d'en-tête If-None-Match DOIT évaluer la condition avant d'exécuter la méthode (Section 5). Si la valeur du champ est "*", la condition est false si le serveur d'origine a une représentation actuelle pour la ressource cible. Si la valeur du champ est une liste de balises d'entité, la condition est false si l'une des balises listées correspond à la balise d'entité de la représentation sélectionnée.

Un serveur d'origine NE DOIT PAS exécuter la méthode demandée si la condition est évaluée à false; au lieu de cela, le serveur d'origine DOIT répondre soit a) par le code d'état 304 (Not Modified) si la méthode de requête est GET ou HEAD, soit b) par le code d'état 412 (Precondition Failed) pour toutes les autres méthodes de requête.

3.3. If-Modified-Since

Le champ d'en-tête If-Modified-Since rend une méthode de requête GET ou HEAD conditionnelle au fait que la date de modification de la représentation sélectionnée soit plus récente que la date fournie dans la valeur du champ. Le transfert des données de la représentation sélectionnée est évité si ces données n'ont pas changé.

If-Modified-Since = HTTP-date

Exemple du champ:

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Un destinataire DOIT ignorer If-Modified-Since si la requête contient un champ d'en-tête If-None-Match; la condition dans If-None-Match est considérée comme un remplacement plus précis de la condition dans If-Modified-Since, et les deux ne sont combinés que dans le but d'interopérer avec des intermédiaires plus anciens qui pourraient ne pas implémenter If-None-Match.

Un destinataire DOIT ignorer le champ d'en-tête If-Modified-Since si la valeur de champ reçue n'est pas une HTTP-date valide, ou si la méthode de requête n'est ni GET ni HEAD.

If-Modified-Since est généralement utilisé à deux fins distinctes: 1) permettre des mises à jour efficaces d'une représentation en cache qui n'a pas de balise d'entité et 2) limiter la portée d'un parcours web aux ressources qui ont récemment changé.

Un serveur d'origine qui reçoit un champ d'en-tête If-Modified-Since DEVRAIT évaluer la condition avant d'exécuter la méthode (Section 5). Le serveur d'origine NE DEVRAIT PAS exécuter la méthode demandée si la date de dernière modification de la représentation sélectionnée est antérieure ou égale à la date fournie dans la valeur du champ; au lieu de cela, le serveur d'origine DEVRAIT générer une réponse 304 (Not Modified), incluant seulement les métadonnées utiles pour identifier ou mettre à jour une réponse précédemment mise en cache.

3.4. If-Unmodified-Since

Le champ d'en-tête If-Unmodified-Since rend la méthode de requête conditionnelle au fait que la date de dernière modification de la représentation sélectionnée soit antérieure ou égale à la date fournie dans la valeur du champ. Ce champ accomplit le même objectif que If-Match pour les cas où l'agent utilisateur n'a pas de balise d'entité pour la représentation.

If-Unmodified-Since = HTTP-date

Exemple du champ:

If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

Un destinataire DOIT ignorer If-Unmodified-Since si la requête contient un champ d'en-tête If-Match; la condition dans If-Match est considérée comme un remplacement plus précis de la condition dans If-Unmodified-Since, et les deux ne sont combinés que dans le but d'interopérer avec des intermédiaires plus anciens qui pourraient ne pas implémenter If-Match.

Un destinataire DOIT ignorer le champ d'en-tête If-Unmodified-Since si la valeur de champ reçue n'est pas une HTTP-date valide.

If-Unmodified-Since est le plus souvent utilisé avec les méthodes modifiant l'état (par exemple POST, PUT, DELETE) pour éviter les écrasements accidentels lorsque plusieurs agents utilisateurs peuvent agir en parallèle sur une ressource qui ne fournit pas de balises d'entité avec ses représentations (c'est-à-dire pour éviter le problème de "mise à jour perdue").

Un serveur d'origine qui reçoit un champ d'en-tête If-Unmodified-Since DOIT évaluer la condition avant d'exécuter la méthode (Section 5). Le serveur d'origine NE DOIT PAS exécuter la méthode demandée si la date de dernière modification de la représentation sélectionnée est plus récente que la date fournie dans la valeur du champ; au lieu de cela, le serveur d'origine DOIT répondre soit a) par le code d'état 412 (Precondition Failed), soit b) par l'un des codes d'état 2xx (Successful) si le serveur d'origine a vérifié qu'un changement d'état est demandé et que l'état final est déjà reflété dans l'état actuel de la ressource cible.

Le champ d'en-tête If-Unmodified-Since peut être ignoré par les caches et les intermédiaires car il n'est pas applicable à une réponse stockée.

3.5. If-Range

Le champ d'en-tête If-Range fournit un mécanisme de requête conditionnelle spécial qui est similaire aux champs d'en-tête If-Match et If-Unmodified-Since mais qui instruit le destinataire d'ignorer le champ d'en-tête Range si le validateur ne correspond pas, entraînant le transfert de la nouvelle représentation sélectionnée au lieu d'une réponse 412 (Precondition Failed). If-Range est défini dans la Section 3.2 de [RFC7233].