Afin de déterminer si le document affiché est le plus récent les clients HTTP peuvent envoyer une en-têtes afin de signaler au serveur la version de la copie qu’ils détiennent.
Le validateur le plus couramment utilisé est la date de la dernière modification d’un document, communiquée par l’en-tête Last-Modified. Si la cache conserve une représentation d’un document incluant l’en-tête Last-Modified, le client peut s’en servir afin d’interroger le serveur, avec une requête If-Modified-Since, afin de savoir si la représentation du document a changé depuis la dernière fois où elle a été vue.
C’est fréquemment employé lors de l’obtention d’une page Web (par une requête HTTP GET) cela permet au serveur d’éviter d’envoyer toutes les données quand le client a déjà récupéré celles-ci. Les mêmes en-têtes peuvent être utilisés par toutes les méthodes HTTP (POST, PUT, DELETE, etc.).
HTTP 1.1 a introduit un nouveau type de validateur appelé ETag – « entity-tag ». Les ETag sont des identificateurs uniques générés par un serveur et changés à chaque fois que la représentation du document change. Puisque le serveur contrôle la génération du Etag, les caches ont l’assurance que, si l’Etag correspond à leurs requêtes If-Match, la représentation est réellement la même.
La balise ETag est l’un des nombreux mécanismes que HTTP, le protocole du World Wide Web, fournit pour la validation de la cache Web et qui permet à un client de faire des requêtes conditionnelles. Cela permet aux caches d’être plus efficaces et d’économiser de la bande passante, car un serveur Web n’a pas besoin d’envoyer une réponse complète si le contenu n’a pas changé. Les ETags peuvent également être utilisés pour un contrôle de concurrence optimiste, afin d’empêcher les mises à jour simultanées d’une ressource.
Un ETag est un identificateur opaque attribué par un serveur Web à une version spécifique d’une ressource trouvée via un URI. Si la représentation de la ressource à cette URI change, un ETag différent est attribué. Utilisés de cette manière, les ETags sont similaires aux empreintes digitales et peuvent être comparés rapidement pour déterminer si deux représentations d’une ressource sont identiques.
Bien que ces en-têtes sont facultatifs dans les réponses HTTP. Pour chaque réponse on devrait définir deux en-têtes HTTP : l’en-tête ETag et l’en-tête Last-Modified. La plupart des serveurs Web modernes généreront automatiquement à la fois les validateurs ETag et Last-Modified
Les requêtes conditionnelles tel que décrit ci-dessous permettent d’implémenter un algorithme de verrouillage optimiste – optimistic locking algorithm
Lorsqu’un client demande une nouvelle fois la même ressource, il peut transmettre avec la requête le ETag et/ou Last-Modified. Si la version actuelle de la page dans la base de données correspond à la valeur ETag envoyée par le client ou que la ressource n’a pas été modifiée entre temps, le serveur va envoyer un code de statut 304 (Not modified) au lieu d’une réponse complète, indiquant ainsi au client que rien n’a changé et qu’il peut utiliser le document en cache tel quel. En fonction de l’en-tête, si la page a été modifiée ou ne correspond pas au contenu ETag envoyé par le client, un code de statut 412 (Precondition Failed) sera envoyé.
Les validateur HTTP ETag et Last-Modified font partie de la spécification RFC7232 – Demandes conditionnelles qui est distincte de la spécification RFC7234 – HTTP 1.1 Caching. Par contre compte tenu de leurs définitions ils jouent un rôle dans le document RFC7234.
Last-Modified
- Ce validateur utilise la dernière date de modification d’une ressource. Il est utilisée pour comparer plusieurs versions de la même ressource. Il est moins précis que le validateur
ETag, mais plus facile à calculer. Les requêtes utilisent les conditionsIf-Modified-SinceetIf-Unmodified-Sincepour modifier le comportement de la requête.
ETag
- Ce validateur utilise une chaîne unique (hashing) identifiant la version de la ressource. Les requêtes utilisent les conditions
If-MatchetIf-None-Matchpour modifier le comportement de la requête.
If-Match
- rend la requête conditionnelle et applique la méthode que si la ressource conservée correspond au
ETagdonné. Cette condition est utilisée pour indiquer que la ressource n’a pas été modifiée. On peut l’utiliser dans un GET afin d’éviter d’envoyer les mêmes données au client. On peut l’utiliser dans un PUT afin de faire une mise à jour d’une ressource.
If-None-Match
- rend la requête conditionnelle et applique la méthode que si la ressource conservée ne correspond pas au
ETagdonné. Cette condition est utilisée pour mettre à jour les caches (GET), exemple lors des requêtes sécurisées, ou pour empêcher de mettre à jour (PUT) un document qui a été mis à jour précédement par un autre utilisateur.
If-Modified-Since
- rend la requête conditionnelle et applique la méthode seulement si la ressource a été modifiée après la date donnée. Ceci est utilisé pour transmettre des données (GET) uniquement lorsque le cache est obsolète ou pour empêcher de mettre à jour (PUT) un document qui a été mis à jour précédement par un autre utilisateur.
If-Unmodified-Since
- rend la demande conditionnelle afin de mettre à jour (PUT) la ressource seulement si elle n’a pas été modifiée après la date donnée. Ceci est utilisé pour assurer la cohérence d’une ressource afin d’implémenter un système de contrôle de concurrence optimiste lors de la modification de documents existants ou pour empêcher de télécharger une nouvelle ressource lorsqu’elle existe déjà. On peut l’utiliser dans un GET afin d’éviter d’envoyer les mêmes données au client.
Note : Rappelez-vous que l’heure d’une date HTTP est relative au temps GMT, non au temps local.
- GET une entité correspondant à la ressource demandée est envoyée dans la réponse;
- HEAD les champs d’en-tête d’entité correspondant à la ressource demandée sont envoyés dans la réponse sans aucun corps de message;
- POST une entité décrivant ou contenant le résultat de l’action;
- TRACE une entité contenant le message de demande tel que reçu par le serveur final
Le client NE DEVRAIT PAS modifier la vue du document qui a provoqué l’envoi de la demande. Cette réponse est principalement destinée à permettre la saisie d’actions sans provoquer de modification à la vue du document actif du client, bien que toute nouvelle méta-information ou mise à jour DEVRAIT être appliquée au document actuellement dans la vue active de l’agent utilisateur.
La réponse 204 NE DOIT PAS inclure un corps de message, et est donc toujours terminée par la première ligne vide après les champs d’en-tête
Référence : Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- Le client demande /foo/.
- Le serveur répond avec un contenu dont la valeur
ETagvaut « abcd1234 ». - Le client envoie une requête HTTP PUT vers /foo/ pour mettre à jour la ressource. Il envoie également un en-tête
If-Match: « abcd1234 » pour indiquer la version qu’il tente de mettre à jour. - Le serveur vérifie si la ressource a changé en calculant la valeur
ETagcomme il l’a fait pour la requête GET (en utilisant la même fonction). Si la ressource a effectivement changé, il renvoie un code de statut 412 signifiant « Échec de condition préalable » (precondition failed). - Le client envoie une requête GET vers /foo/ après la réception de la réponse 412 afin de récupérer une version à jour du contenu avant de le mettre à jour à nouveau.
- La précision du validateur
Last-Modified« Tue, 01 Sep 2015 11:28:37 GMT » (précision en secondes) n’est pas suffisamment granulaire pour décider de la fraîcheur de la cache / de l’enregistrement compte tenu de la conditionIf-Modified-Since; - Il existe des situations où l’horodatage d’un fichier ne peut pas être changé, par exemple, si les fichiers sont placés sur un serveur Web et que nous ne sommes pas en mesure de définir l’horodatage compte tenu des restrictions du système d’exploitation, ou encore si vous avez deux serveurs Web avec un équilibreur de charge, ou si vous restaurez un fichier à partir d’une sauvegarde.
Le mécanisme ETag supporte à la fois une validation forte et une validation faible. Une validation faible se distinguent par la présence d’un « W / » pour « Weak » dans l’identifiant ETag, comme:
- « 123456789 » – Un validateur ETag fort
- « W / « 123456789 » – Un validateur ETag faible
Une correspondance ETag à validation forte indique que le contenu des deux représentations d’une ressource sont identique octet par octet et que tous les autres champs d’entité (tels que Content-Language) sont également inchangés.
Une correspondance ETag faiblement validée indique seulement que les deux représentations sont sémantiquement équivalentes, ce qui signifie que, pour des raisons pratiques, elles sont interchangeables et que des copies en cache peuvent être utilisées. Cependant, les représentations de la ressource ne sont pas nécessairement identiques à l’octet près. Un Weak ETags peut être utile dans le cas où des ETags puissants ne sont pas pratiques pour un serveur Web, par exemple avec du contenu généré dynamiquement.
Le validateur Last-Modified est implicitement faible – Weak – à moins qu’il soit possible d’en déduire qu’il est fort selon certains critères voir le RFC-7232 section 2.2.2
La méthode par laquelle le validateur ETag doit être généré n'est pas spécifiée dans la spécification HTTP (RFC-7232). Les méthodes courantes de génération du validateur ETag comprennent l'utilisation d'une fonction de hachage (checksum CRC32/CRC64/MD5, etc) résistant à la collision du contenu de la ressource, un hachage de la dernière date de modification, etc. Afin d'éviter l'utilisation des données de cache obsolètes, la méthode utilisée pour générer un ETag devrait garantir (autant que cela est possible) que chaque ETag est unique. Cependant, une fonction de génération d'un validateur ETag peut être jugée « utilisable » si l'on peut prouver (mathématiquement) que la duplication des ETags serait « rare », même si elle pouvait se produire.
La meilleure méthode sera basée sur un contrôle de révision strict, dans lequel chaque modification d'une représentation entraîne toujours un ETag unique assigné. Ce ETag devrait être disponibles avant que les champs d'en-tête de réponse soient envoyés et il ne devrait pas être nécessaire de recalculé cette valeur chaque fois qu'une demande de validation est requise. Si une ressource a des représentations distinctes selon ses métadonnées, comme cela pourrait se produire avec le contenu de type média qui partagent les mêmes données et le même format, le serveur d’origine devrait alors incorporer des informations supplémentaire dans le validateur pour distinguer ces représentations afin d'en faire un "validateur fort".
Un "validateur faible" est celui qui ne change pas pour chaque modification des données de représentation. Cette faiblesse pourrait être due à des limites dans le calcul de la valeur, tels que la résolution d'horloge, une incapacité à assurer l'unicité pour toute les représentations possibles de la ressource, ou le désir du propriétaire de la ressource de regrouper des représentations dans un ensemble auto-déterminé d'équivalence plutôt que des séquences de données uniques. Un serveur d'origine DEVRAIT changer une étiquette d'entité faible à chaque fois que celui-ci considère que les représentations sont inacceptables comme substitut a la représentation courante. En d'autres termes, une étiquette d'entité faible devrait changer chaque fois que le serveur d'origine souhaite que les caches invalident les anciennes réponses.
À titre d'exemple, la représentation d’un bulletin météo qui change son contenu chaque seconde, basé sur des mesures dynamiques, pourrait être regroupé dans des ensembles de représentations équivalentes (à partir du serveur d'origine) avec le même validateur faible afin de permettre la mise en cache d'une représentation valable pour une période de temps raisonnable (peut-être ajusté dynamiquement en fonction de la charge du serveur ou selon le niveau de changement de la température). De même, l'heure de modification d'une représentation, si elle est définie avec seulement les secondes, peut être un validateur faible lorsque la représentation est modifiée deux fois en une seule seconde et récupéré entre ces modifications.
De même, un validateur est faible s'il est partagé par plus de deux représentations d'une ressource donnée en même temps, à moins que ces représentations des données soient identiques. Par exemple, si le serveur d'origine envoie le même validateur pour une représentation avec un codage de contenu gzip appliqué comme pour une représentation sans le codage de contenu, alors ce validateur est faible.
Lors d’un GET le serveur renvoie la représentation actuelle de la ressource avec sa valeur ETag correspondante, qui est placée dans un champ d’en-tête de réponse HTTP « ETag »: "ETag: "686897696a7c876b7e"
Le client peut alors décider de mettre la représentation en cache avec son ETag. Par la suite, si le client souhaite récupérer à nouveau la même ressource URL, il déterminera d’abord si la version en cache locale de l’URL a expiré (via les en-têtes Cache-Control et Expire). Si l’URL n’a pas expiré, il récupérera la ressource en cache locale. S’il est déterminé que l’URL a expiré (est périmée), le client contactera le serveur et enverra sa copie précédemment enregistrée de l’ETag avec la demande dans un champ If-None-Match
"If-None-Match: "686897696a7c876b7e" via cette requête, le serveur peut maintenant comparer l’ETag du client avec l’ETag de la version actuelle de la ressource. Si les valeurs ETag correspondent, ce qui signifie que la ressource n’a pas changé, le serveur devrait transmettre une réponse très courte avec un statut HTTP 304 non modifié. Le statut 304 indique au client que sa version en cache est toujours correcte et qu’elle doit l’utiliser.
Cependant, si les valeurs ETag ne correspondent pas, ce qui signifie que la ressource a probablement changé, une réponse complète incluant le contenu de la ressource est renvoyée, comme si les ETags n’étaient pas utilisés. Dans ce cas, le client peut décider de remplacer sa version précédemment mise en cache par la nouvelle représentation de la ressource et du nouvel ETag.
Les valeurs ETag peuvent être utilisées dans les systèmes de surveillance de pages Web. La surveillance efficace des pages Web est entravée par le fait que la plupart des sites Web ne définissent pas les en-têtes ETag pour les pages Web. Lorsqu’un moniteur Web n’a aucune indication quant à la modification du contenu Web, tout le contenu doit être extrait et analysé à l’aide des ressources informatiques à la fois pour l’éditeur et l’abonné.
Notez que le client ne vérifie pas les en-têtes pour voir si elles ont changés; il les utilise simplement aveuglément. Il appartient au serveur d’évaluer s’il convient d’envoyer le contenu demandé et l’un des codes HTTP suivants : 200 – OK, 204 – Not content, 304 – Not Modified, 412 – Precondition Failed, etc.
Table of contents
Cette trace montre une situation où le document existe déjà.
- Le client a téléchargé la version existante via la méthode GET et il a récupéré le ETag « jrbkiq:qhcjujp0 »
- Le client prend la décision de remplacer la version courante via la méthode PUT et en passant la condition If-Match : « jrbkiq:qhcjujp0 »
18.29.0.116.1311 -> 18.29.0.24.80 over TCP PUT /frystyk/test/test.html HTTP/1.1. Accept: */*;q=0.3. Accept-Encoding: deflate. TE: trailers,deflate. Expect: 100-continue. Host: jigedit.w3.org. If-Match: "jrbkiq:qhcjujp0". User-Agent: WebCommander/1.1 libwww/5.2.1. Connection: TE. Date: Wed, 25 Nov 1998 22:00:25 GMT. Content-Length: 104. Content-Type: text/html. Last-Modified: Fri, 04 Sep 1998 12:50:18 GMT.
Compte tenu que le document n’a pas été modifié du côté du serveur par un autre utilisateur ce dernier sera mis à jour et un nouveau ETag sera retourné au client.
18.29.0.24.80 -> 18.29.0.116.1311 over TCP HTTP/1.1 204 No Content. Date: Wed, 25 Nov 1998 22:00:28 GMT. Content-Length: 104. Content-Type: text/html. Etag: "jrbkiq:qhcko64g". Last-Modified: Wed, 25 Nov 1998 22:00:28 GMT. Server: Jigsaw/2.0beta1.
Cette trace montre une situation où le document a été mis à jour par un autre utilisateur
Cette trace montre une situation où un autre utilisateur a mis à jour le document et la balise ne correspond plus. La demande PUT échoue et l’utilisateur a la possibilité de télécharger la nouvelle version et d’écraser la version existante. Dans ce dernier cas, nous remplaçons la version existante en incluant le champ d’en-tête If-None-Match avec le même ETag que celui utilisé dans le champ d’en-tête If-Match. Dans les deux cas, le nouvel ETtag renvoyé est enregistré dans la cache et l’ancien ETag est supprimé.
- Le client a téléchargé la version existante via la méthode GET et il a récupéré le ETag « jrbkiq:qhcii3ug »
- Le client prend la décision de remplacer la version courante via la méthode PUT et en passant la condition If-Match : « jrbkiq:qhcii3ug »
18.29.0.116.1297 -> 18.29.0.24.80 over TCP PUT /frystyk/test/test.html HTTP/1.1. Accept: */*;q=0.3. Accept-Encoding: deflate. TE: trailers,deflate. Expect: 100-continue. Host: jigedit.w3.org. If-Match: "jrbkiq:qhcii3ug". User-Agent: WebCommander/1.1 libwww/5.2.1. Connection: TE,Keep-Alive. Date: Wed, 25 Nov 1998 21:46:19 GMT. Content-Length: 104. Content-Type: text/html. Last-Modified: Fri, 04 Sep 1998 12:50:18 GMT.
Le serveur n’accepte pas la mise à jour compte tenu que le document a été mis à jour par un autre utilisateur et que le ETag sur le serveur ne correspond pas à celui transmis par le client. L’utilisateur doit faire à nouveau un « GET » afin d’obtenir la dernière version du document.
18.29.0.24.80 -> 18.29.0.116.1297 over TCP HTTP/1.1 412 Precondition Failed. Date: Wed, 25 Nov 1998 21:46:23 GMT. Transfer-Encoding: deflate,chunked. Content-Type: text/html. Server: Jigsaw/2.0beta1. . 1D. x..(J.M..K.,...SHK..IM...W....
Ou le serveur peut accepter de remplacer la version courante pour ce faire le client peut changer la condition « If-Match » par la condition « If-None-Match » afin d’écraser la version courante.
18.29.0.116.1297 -> 18.29.0.24.80 over TCP PUT /frystyk/test/test.html HTTP/1.1. Accept: */*;q=0.3. Accept-Encoding: deflate. TE: trailers,deflate. Expect: 100-continue. Host: jigedit.w3.org. If-None-Match: "jrbkiq:qhcii3ug". User-Agent: WebCommander/1.1 libwww/5.2.1. Connection: TE. Date: Wed, 25 Nov 1998 21:46:26 GMT. Content-Length: 104. Content-Type: text/html. Last-Modified: Fri, 04 Sep 1998 12:50:18 GMT. .
Le nouveau ETag est enregistré dans le serveur et retourné dans la cache du client.
18.29.0.24.80 -> 18.29.0.116.1297 over TCP HTTP/1.1 204 No Content. Date: Wed, 25 Nov 1998 21:46:29 GMT. Content-Length: 104. Content-Type: text/html. Etag: "jrbkiq:qhcjujp0". Last-Modified: Wed, 25 Nov 1998 21:46:29 GMT. Server: Jigsaw/2.0beta1. .
Cette trace montre une situation où le document n’existe pas et la demande PUT est exécutée normalement
Le document n’existe pas le ETag n’est pas connue. La valeur est « * »
18.29.0.116.1270 -> 18.29.0.24.80 over TCP PUT /frystyk/test/test.html HTTP/1.1. Accept: */*;q=0.3. Accept-Encoding: deflate. TE: trailers,deflate. Expect: 100-continue. Host: jigedit.w3.org. If-None-Match: *. User-Agent: WebCommander/1.1 libwww/5.2.1. Connection: TE. Date: Wed, 25 Nov 1998 21:22:09 GMT. Content-Length: 104. Content-Type: text/html. Last-Modified: Fri, 04 Sep 1998 12:50:18 GMT. .
Le document est sauvegardé dans le serveur et le ETag « jrbkiq:qhcii3ug » est retourné
18.29.0.24.80 -> 18.29.0.116.1270 over TCP HTTP/1.1 201 Created. Date: Wed, 25 Nov 1998 21:22:11 GMT. Transfer-Encoding: deflate,chunked. Content-Type: text/html. Etag: "jrbkiq:qhcii3ug". Location: http://jigedit.w3.org/frystyk/test/test.html. Server: Jigsaw/2.0beta1. . 2A. x..).s.+.,.TH.O.T(N,KMQ(.MNN-N+...TP.....|.
Dans ce qui suit, nous examinerons deux scénarios:
- L’utilisateur enregistre un document pour la première fois. Ce document peut ou non exister – l’utilisateur ne le sait pas;
- L’utilisateur enregistre un document pour une seconde fois ou ultérieurement. L’utilisateur sait que le document existe mais ne sait pas si quelqu’un d’autre l’a modifié.
Enregistrement d’un document dont le client ne sais pas s’il existe sur le serveur
Si l’utilisateur souhaite enregistrer un document pour lequel il ne sait pas si le serveur en a une copie, le client doit d’abord vérifier si c’est correct ou non. Cela se fait en émettant une requête HEAD/GET avant d’effectuer la sauvegarde réelle en utilisant une requête PUT. À titre d’exemple le client pourrait vérifier au préalable si l’adresse de résidence principale est déjà présente avant de tenter de créer une nouvelle adresse de résidence principale ou de remplacer celle existante.
Enregistrer un document dont le client connait l’existence sur le serveur
Lorsqu’un nouveau document a été créé sur le serveur, le serveur répond avec une réponse 201 (créé), et comprenant l’ETag de la ressource créée. Cet ETag est conservé dans le cache HTTP / 1.1 persistant du client. Une fois que l’ETag est connu, il sera utilisé par toutes les requêtes PUT suivantes dans un champ d’en-tête If-match. Si le document n’a pas changé, les ETags correspondent, et le PUT peut continuer. Cependant, si le document a changé, les ETags ne correspondront plus et le PUT ne pourra pas continuer.
Détection d’un conflit
Lorsqu’un conflit est détecté, soit parce qu’une précondition échoue ou qu’une requête HEAD/GET indique qu’une ressource existe déjà, l’utilisateur peut se voir proposer deux choix:
- télécharger la dernière révision du document en provenance du serveur pour que l’utilisateur puisse effectuer une fusion à l’aide d’un mécanisme indépendant du côté client;
- ou remplacer la version existante sur le serveur par celle du client;
Si l’utilisateur souhaite remplacer la révision existante sur le serveur, une deuxième demande PUT doit être émise. Selon que le document était initialement connu ou non, le client peut soit :
- S’il est connu, le client va émettre une nouvelle requête PUT qui inclut un champ d’en-tête If-None-Match avec le même ETag que celui utilisé dans le champ d’en-tête If-match de la première demande PUT – Il va ainsi écraser une version mise à jour par un autre utilisateur, ou
- S’il n’est pas connu, le client va émettre une nouvelle demande PUT qui inclut un If-Match avec l’ETag de la ressource existante sur le serveur. Le ETag aura été reçu dans la réponse de la demande HEAD/GET initiale ou en soumettant à nouveau la demande PUT sans condition préalable. Cependant, l’avantage de l’utilisation de la condition préalable est qu’habituellement le serveur va bloquer toutes les requêtes PUT qui n’ont pas de condition préalable, car il est probable que ces requêtes proviennent de clients sans connaissance des ETags et des conditions préalables.
Note : Une solution plus sophistiquée pourrait impliquer que le serveur tente de fusionner le contenu à la volée. Pour ce faire il suffit que le serveur accepte la demande et qu’il transmette les différences au client, mais cela nécessite des fonctionnalités qui ne sont pas directement prises en charge par HTTP / 1.1.
- RFC 7230 – Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
- RFC 7231 – Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
- RFC 7232 – Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
- RFC 7233 – Hypertext Transfer Protocol (HTTP/1.1): Range Requests
- RFC 7234 – Hypertext Transfer Protocol (HTTP/1.1): Caching
- RFC 7235 – Hypertext Transfer Protocol (HTTP/1.1): Authentication
- Detecting the Lost Update Problem Using Unreserved Checkout
- Wiki Mozilla sur le HTTP