web-dev-qa-db-fra.com

Quelle est la fonction de l'en-tête HTTP "Vary: Accept"?

J'utilise PHP pour générer des pages Web dynamiques. Comme indiqué dans le tutoriel suivant (voir le lien ci-dessous), le type MIME des documents XHTML doit être "application/xhtml + xml" lorsque $ _SERVER [' HTTP_ACCEPT '] le permet. Étant donné que vous pouvez servir la même page avec 2 MIME différents ("application/xhtml + xml" et "text/html"), vous devez définir l'en-tête HTTP "Vary" sur "Accepter". cache sur les proxies.

Lien: http://keystonewebsites.com/articles/mime_type.php

Maintenant, je ne suis pas sûr de l'implication de: header ('Vary: Accept'); Je ne suis pas vraiment sûr de ce que fera 'Vary: Accepter' ...

La seule explication que j'ai trouvée est:

Après l'en-tête Content-Type, un en-tête Vary est envoyé à (si je le comprends bien) pour indiquer aux caches intermédiaires, comme les serveurs proxy, que le type de contenu du document varie en fonction des capacités du client qui demande le document. http://www.456bereastreet.com/archive/200408/content_negotiation/

Tout le monde peut me donner une "vraie" explication de cet en-tête ( avec cette valeur ). Je pense que je comprends des choses comme: Vary: Accept-Encodage où le cache sur les proxies pourrait être basé sur l'encodage de la page servie, mais je ne comprends pas: Vary: Accept

httpcachingproxy
89
AlexV

  • Le cache-control en-tête est le principal mécanisme utilisé par un serveur HTTP pour indiquer à un proxy de mise en cache la "fraîcheur" d'une réponse. (c'est-à-dire, combien de temps/combien de temps pour stocker la réponse dans le cache)

  • Dans certaines situations, cache-control les directives sont insuffisantes. Une discussion du groupe de travail HTTP est archivée ici, décrivant une page qui change uniquement avec la langue. Ceci est pas le cas d'utilisation correct pour l'en-tête de variation, mais le contexte est précieux pour notre discussion. (Bien que je pense que l'en-tête Vary résoudrait le problème dans ce cas, il existe un meilleur moyen.) À partir de cette page:

Vary est strictement réservé aux cas où il est sans espoir ou excessivement compliqué pour un proxy de répliquer ce que le serveur ferait.

Un exemple artificiel:

Votre serveur HTTP a une grande page de destination. Vous avez deux pages légèrement différentes avec la même URL, selon que l'utilisateur y est déjà allé. Vous faites la distinction entre les demandes et le "nombre de visites" d'un utilisateur basé sur les cookies. Mais, comme la page de destination de votre serveur est très volumineuse, vous souhaitez que les mandataires intermédiaires mettent en cache la réponse, si possible.

Les en-têtes URL, Last-Modified et Cache-Control sont insuffisants pour donner cet aperçu à un proxy de mise en cache, mais si vous ajoutez Vary: Cookie, le moteur de cache ajoute l’en-tête Cookie à ses décisions de mise en cache.

Enfin, pour les sites Web dynamiques à faible trafic, j'ai toujours trouvé le simple Cache-Control: no-cache, no-store et Pragma: no-cache suffisant.

Éditer - pour répondre plus précisément à votre question: l'en-tête de la requête HTTP "Accepter" définit les types de contenu qu'un client peut traiter. Si vous avez deux copies du même contenu sur la même URL, ne différant que par Content-Type, utilisez Vary: Accept pourrait être approprié.

Mise à jour 11 du 12 septembre:

J'inclus quelques liens apparaissant dans les commentaires depuis la publication initiale de ce commentaire. Ce sont deux excellentes ressources pour des exemples concrets (et des problèmes) avec Vary: Accepter; Si vous lisez cette réponse, vous devez également lire ces liens.

Le premier, tiré de l'excellent EricLaw, porte sur le comportement d'Internet Explorer avec l'en-tête Vary et sur certains des défis qu'il présente pour les développeurs: Vary Header empêche la mise en cache dans IE . En bref, IE (pre IE9) ne met en cache aucun contenu utilisant l'en-tête Vary, car le cache de la requête n'inclut pas d'en-têtes de requête HTTP. EricLaw (Eric Lawrence dans le monde réel) est un programme Gestionnaire de l’équipe IE.

La seconde, d’Eran Medan, est une discussion en cours sur le comportement inattendu de Vary dans Chrome: le support ne gère pas correctement l’entête de Vary . Cela est lié au comportement d'IE, à l'exception du Chrome devs a adopté une approche différente - bien que cela ne semble pas avoir été un choix délibéré.

93
J.J.

Vary: Accept indique simplement que la réponse a été générée en fonction de l’en-tête Accept de la demande. Une demande avec un en-tête Accept différent pourrait obtenir une réponse différente.

(Vous pouvez voir que le code lié PHP ressemble à $HTTP_ACCEPT. C'est la valeur de l'en-tête de la demande Accept.)

Pour les caches HTTP, cela signifie que la réponse doit être mise en cache avec une prudence accrue. Cela ne fera que correspondre aux demandes ultérieures avec exactement le même en-tête Accept.

À présent, cela n'a d'importance que si la page peut être mise en mémoire cache en premier lieu. Par défaut, PHP pages ne sont pas. Une page PHP page peut marquer le résultat comme pouvant être mis en cache en envoyant certains en-têtes (Expires, par exemple ). Mais si et comment faire est une question différente.

55
Jason Orendorff

Il existe actuellement un nombre important de nouvelles fonctionnalités à venir (et déjà dans Chrome) qui rendent l'en-tête Vary extrêmement utile. Par exemple, considérons Indice client . Par exemple, lorsqu’il est utilisé en liaison avec des images, l’indication de client permet à un serveur d’optimiser des ressources telles que des images en fonction de:

  • Largeur de l'image
  • Largeur de la fenêtre
  • Type d'encodage supporté par le navigateur (think WebP)
  • Liaison descendante (essentiellement la vitesse du réseau)

Ainsi, un serveur prenant en charge ces fonctionnalités définirait l'en-tête Vary pour l'indiquer.

Chrome annonce le support WebP en définissant "image/webp" dans l'en-tête Vary de chaque demande. Ainsi, un serveur peut réécrire une image en tant que WebP si le navigateur le prend en charge. Le proxy doit donc vérifier l'en-tête afin de ne pas mettre en cache une image WebP, puis le transmettre à un navigateur qui ne prend pas en charge WebP. Évidemment, si votre serveur ne fait pas cela, cela n’a aucune importance. Donc, puisque la réponse du serveur varie dans l'en-tête de la demande Accept, elle doit inclure cette réponse pour ne pas confondre les mandataires:

Vary: Accept

Un autre exemple pourrait être la largeur de l'image. Sur un navigateur mobile, l'en-tête Width peut être assez petit pour une image sensible, par rapport à ce qu'il serait s'il était affiché à partir d'un navigateur de bureau. Donc, dans ce cas, Width serait ajouté à l'en-tête Vary est essentiel pour que le proxy ne mette pas en cache la version mobile de petite taille et ne la serve pas pour les navigateurs de bureau, ou inversement. Dans ce cas, l'en-tête pourrait inclure:

Vary: Accept, Width

Ou dans le cas où un serveur prend en charge toutes les spécifications d'indication de client, l'en-tête serait quelque chose comme:

Vary: Accept, DPR, Width, Save-Data, Downlink
2
Brad Berger

Ce google webmaster video explique très bien HTTP en-tête HTTP Vary.

1
Kannan Mohan