Pourquoi le navigateur n'envoie pas de “Si-None-Match” en-tête?

Même Problème, Solution Similaire

J'ai été d'essayer de déterminer pourquoi Google Chrome n'enverrons pas de If-None-Match en-têtes lors de la visite d'un site que je suis en train d'élaborer. (Chrome 46.0.2490.71 m, bien que je ne suis pas sûr de la pertinence de la version.)

C'est une façon différente, bien que très similaire — réponse de l'OP, finalement, cité dans un commentaire au sujet de la Accepté de Répondre), mais il traite du même problème:

Le navigateur n'envoie pas le If-None-Match d'en-tête dans les demandes ultérieures "quand il le faut" (c'est à dire, une logique côté serveur, via PHP ou similaire, a été utilisé pour envoyer un ETag ou Last-Modified d'en-tête dans la première réponse).

Conditions préalables

À l'aide d'un auto-signé certificat TLS, qui tourne le verrou rouge en Chrome, les changements de google Chrome comportement de mise en cache. Avant de tenter de résoudre un problème de cette nature, installer le certificat auto-signé dans la banque de Racine de Confiance, et de redémarrer complètement le navigateur, comme l'explique l' https://stackoverflow.com/a/19102293 .

1er Épiphanie: Si-None-Match exige un ETag à partir du serveur, premier

Je me suis rendu compte assez rapidement que Chrome (et probablement les la plupart ou tous les autres navigateurs) de ne pas envoyer un If-None-Match en-tête jusqu'à ce que le serveur a déjà envoyé un ETag - tête en réponse à une demande précédente. Logiquement, c'est parfaitement logique; après tout, comment pourrait-Chrome envoyer If-None-Match lorsqu'il n'est jamais été donné de la valeur?

Cela m'amener à regarder ma logique côté serveur — en particulier, comment les en-têtes sont envoyés quand je veux le user-agent pour mettre en cache la réponse — dans un effort pour déterminer pour quelle raison le ETag - tête n'est pas envoyé en réponse à google Chrome de la première demande de la ressource. J'avais fait un effort calculé pour inclure le ETag d'en-tête dans ma logique de l'application.

M'arrive d'être en utilisant PHP, donc @Mehran (l'OP) commentaire a sauté hors de moi (il/elle dit que l'appel header_remove() avant d'envoyer le désiré lié au cache-têtes résout le problème).

Franchement, j'étais sceptique à propos de cette solution, parce que a) je suis presque sûr que PHP ne pas envoyer les en-têtes de ses propres par défaut (et il n'a pas, compte tenu de ma configuration); et b) lorsque j'ai appelé var_dump(headers_list()); juste avant de mettre mon custom de la mise en cache des en-têtes en PHP, la seule tête de série a été l'une que j'ai été la mise intentionnellement juste au-dessus:

header('Content-type: application/javascript; charset=utf-8');

Donc, n'ayant rien à perdre, j'ai essayé d'appeler header_remove(); juste avant l'envoi de mon en-têtes personnalisés. Et à ma grande surprise, PHP a commencé à envoyer de l' ETag - tête tout d'un coup!

2e Épiphanie: gzipping les changements de réponse de son hachage

Puis, il me m'a frappé comme un sac de briques: en spécifiant le Content-type header en PHP, je parlais de NGINX (le serveur que j'utilise) pour GZIP la réponse, une fois PHP mains en arrière de NGINX! Pour être clair, la Content-type que j'étais en précisant était sur NGINX la liste des types de gzip.

Pour la perfection, mon NGINX GZIP paramètres sont définis comme suit, et PHP est câblé pour NGINX via php-fpm:

gzip            on;
gzip_min_length 1;
gzip_proxied    expired no-cache no-store private auth;
gzip_types      text/plain text/css application/json application/x-javascript text/xml application/xml application/xml+rss text/javascript application/javascript image/svg+xml;

gzip_vary on;

J'ai réfléchi à pourquoi NGINX peut supprimer le ETag que j'avais envoyé en PHP quand un "gzippable" content-type est spécifié, et est venu avec une réponse évidente: parce que NGINX modifie le corps de la réponse que PHP passe en arrière quand NGINX fichiers gzip il! Cela fait beaucoup de sens; il n'y a pas de point dans l'envoi de la ETag quand ça ne va pas correspondre à la réponse utilisé pour les générer. C'est assez noire qui NGINX gère ce scénario est si intelligemment.

Je ne sais pas si NGINX a toujours été assez intelligent pour ne pas compresser la réponse des organismes qui sont non compressé, mais contiennent ETag les en-têtes de, mais cela semble être ce qui se passe ici.

Mise à JOUR: j'ai trouvé commentaire qui explique NGINX du comportement à cet égard, qui cite deux de riches discussions à ce sujet:

1. NGINX fil de discussion du forum de discuter le comportement.
2. Tangentiellement aux débats sur un projet de référentiel; voir le commentaire Posted on Jun 15, 2013 by Massive Bird.

Dans l'intérêt de la préservation de ce précieux explication, s'il arrive à disparaître, je cite Massive Birdcontribution à la discussion:

Nginx bandes de l'Etag quand gzipping une réponse à la volée. C'est
selon les spécifications, comme la non-gzippé réponse n'est pas de l'octet-par-octet
comparable au format gzip réponse.

Cependant, NGINX du comportement à cet égard pourrait être considéré comme un peu imparfait en ce que le même spec

... aussi dit qu'il y a un truc qui s'appelle la faiblesse des Etags (une valeur Etag
avec le préfixe W/), et nous indique qu'il peut être utilisé pour vérifier si une réponse
est sémantiquement équivalent. Dans ce cas, Nginx ne devraient pas gâcher
c'. Malheureusement, cette case ne l'a jamais fait dans l'arborescence des sources [citation est maintenant rempli de spam, malheureusement]."

Je ne suis pas sûr de NGINX actuelle de disposition à cet égard, et en particulier, si oui ou non il a ajouté le support pour les "faibles" les Etags.

Alors, Quelle est la Solution?

Alors, quelle est la solution pour obtenir ETag de nouveau dans la réponse? Faire le gzipping en PHP, de sorte que NGINX voit que la réponse est déjà compressé, et tout simplement de passe ainsi que, tout en laissant la ETag en-tête intacte:

ob_start('ob_gzhandler');

Une fois que j'ai ajouté à cet appel avant d'envoyer les en-têtes et le corps de la réponse, PHP a commencé à envoyer de l' ETag valeur à chaque réponse. Oui!

Autres Leçons Apprises

Voici quelques détails intéressants glanés au fil de mes recherches. Cette information est plutôt pratique lorsque l'on tente de tester un serveur de mise en cache côté mise en œuvre, que ce soit en PHP ou un autre langage.

Chrome, et de ses Outils de développement "Net" du panneau, de se comporter différemment en fonction de la façon dont la demande est initiée.

Si la demande est "frais", par exemple, en appuyant sur Ctrl+F5, Chrome envoie ces en-têtes:

Cache-Control: no-cache
Pragma: no-cache

et le serveur répond 200 OK.

Si la demande est faite avec seulement F5, Chrome envoie ces en-têtes:

Pragma: no-cache

et le serveur répond 304 Not Modified.

Enfin, si la demande est faite en cliquant sur un lien de la page que vous êtes en train de visualiser, ou mettant l'accent sur Chrome la barre d'adresse et en appuyant sur Entrée, Chrome envoie ces en-têtes:

Cache-Control: no-cache
Pragma: no-cache

et le serveur répond 200 OK (from cache).

Alors que ce comportement un peu déroutant au premier abord, si vous ne savez pas comment il fonctionne, il est idéal de comportement, parce qu'il permet de tester tous les possible de requête/réponse scénario très bien.

Peut-être le plus déroutant, c'est que Chrome insère automatiquement le Cache-Control: no-cache et Pragma: no-cache les en-têtes dans le sortant du demande alors qu'en fait, Chrome est d'acquérir les réponses de son cache (comme en témoignent les 200 OK (from cache) réponse).

Cette expérience a été plutôt instructif pour moi, et j'espère que d'autres trouvent cette analyse de la valeur dans le futur.

Ce qui m'est arrivé, grâce à 2 raisons:

1. Mon serveur n'envoie pas etag en-tête de réponse. J'ai mis à jour mon jetty web.xml pour revenir etag par adjonction de ce qui suit:

   <init-param>
       <param-name>etags</param-name>
       <param-value>true</param-value>
   </init-param>
   

2. L'URL que j'ai appelé a pour fichier xml. Quand je l'ai changé pour un fichier html, chrome a commencé à envoyer des "si-none-match" en-tête de!

J'espère que cela aide quelqu'un

Ce qui se passait pour moi parce que j'avais mis de la taille de la mémoire cache trop petit (via la Stratégie de Groupe).

Il n'est pas arrivé dans Incognito, qui est ce qui m'a fait réaliser ce qui pourrait être le cas.

De fixation qui a résolu le problème.