si-modifié-depuis vs si-aucune-correspondance
Quelle pourrait être la différence entre if-modified-since et if-none-match? J'ai le sentiment que if-no-match est utilisé pour les fichiers alors que if-modified-since est utilisé pour les pages?
En ce qui concerne les différences entre Last-Modified/If-Modified-Since et ETag/If-None-Match:
Les deux peuvent être utilisés de manière interchangeable. Cependant, en fonction du type de ressource et de la manière dont elle est générée sur le serveur, l'une ou l'autre question ("cela a-t-il été modifié depuis ...?"/"Cela correspond-il toujours à cet ETag?") Peut être plus facile à répondre .
Exemples:
- Si vous distribuez des fichiers, la solution la plus simple consiste à utiliser la variable
mtimedu fichier comme dateLast-Modified. - Si vous gérez une page Web dynamique construite à partir d'un certain nombre de requêtes SQL, il peut s'avérer impossible de vérifier si les données renvoyées par l'une de ces requêtes ont changé (à moins que toutes ne comportent une sorte de colonne "dernière modification"). Dans ce cas, en utilisant par exemple un hachage md5 du contenu de la page sous la forme
ETagsera beaucoup plus facile.
OTOH, cela signifie que vous devez toujours générer la page entière sur le serveur, même pour un GET conditionnel. Déterminer ce qui doit entrer exactement dans l'ETag (clés primaires, numéros de révision, etc.) peut vous faire gagner beaucoup de temps.
Voir ces liens pour plus de détails sur le sujet:
If-Modified-Since est comparé au Last-Modified alors que If-None-Match est comparé à ETag . Modified-Since et ETag peuvent être utilisés pour identifier une variante spécifique d'une ressource.
Mais la comparaison de If-Modified-Since à Last-Modified vous indique si la variante en cache est plus ancien ou plus récent, alors que la comparaison de If-None-Match à ETag vous indique simplement si les deux sont identiques ou non. De plus, la plupart des générateurs ETag incluent-ils les informations propres au système inode , de sorte que le déplacement d’un fichier sur un lecteur différent peut également modifier la variable ETag.
La valeur d'horodatage utilisée dans Last-Modified/If-Modified-Since a une précision limitée - une seconde et ce n'est tout simplement pas suffisant pour un contenu à changement rapide, comme par exemple une application de discussion Web où plusieurs messages peuvent être envoyés à la seconde . ETag/If-None-Match peut aider à résoudre ce problème.
Comme indiqué dans les meilleures pratiques de Google:
Il est important de spécifier l'une des options Expires ou Cache-Control max-age, et l'une de Last-Modified ou ETag pour toutes les ressources pouvant être mises en cache. Il est redondant de spécifier Expires et Cache-Control: max-age ou de spécifier Last-Modified et ETag.
https://developers.google.com/speed/docs/best-practices/caching
If-Modified-Since utilise une date, tandis que If-None-Match utilise un ETag . Ils peuvent tous deux être utilisés pour des "pages" (c'est-à-dire HTML) et d'autres fichiers.
Sauf si indiqué par le serveur comme étant faible, un ETag est considéré comme un validateur puissant et peut donc être utilisé pour satisfaire une demande à distance conditionnelle. Cependant, la plupart des ETags générés automatiquement présentent des difficultés dans les situations de batterie de serveurs, car ils utilisent souvent des informations inode et/ou un compteur persistant unique. En pratique, j’ai trouvé que l’en-tête Last Modified était suffisant pour un contenu relativement statique, par exemple. servir du contenu statique protégé, car le temps d'écriture du fichier est un assez bon validateur.
L'ETag est de loin le plus flexible. Les clients conformes sont tenus d'envoyer l'ETag dans une demande conditionnelle, alors qu'ils DEVRAIENT envoyer les deux s'ils sont disponibles.
L'en-tête If-Modified-Since est utilisé pour spécifier l'heure à laquelle le navigateur a reçu la ressource demandée pour la dernière fois. L'en-tête If-None-Match est utilisé pour spécifier la balise d'entité que le serveur a émise avec la ressource demandée lors de sa dernière réception.
Dans les deux manières décrites, ces en-têtes sont utilisés pour prendre en charge la mise en cache du contenu dans le navigateur et permettent au serveur de demander au navigateur d'utiliser une copie en cache d'une ressource, plutôt que de répondre avec le contenu complet de la ressource s'il en est pas nécessaire.