Ich versuche, ein dynamisch geladenes Bild in PHP herunterzuladen (und hoffentlich zwischenzuspeichern). Hier sind die Header gesendet und empfangen:

Anfrage:

Antwort:

Wenn ich die URL neu lade, werden genau dieselben Header gesendet und empfangen. Meine Frage ist, was ich in meiner Antwort senden sollte, um den Header If-None-Match in der konsequenten Anfrage zu sehen?

HINWEIS: Ich glaube, dass diese Header vor nicht allzu langer Zeit gut waren, obwohl ich nicht sicher sein kann, aber ich denke Browser werden geändert, um den Header If-None-Match nicht mehr zu senden (ich sah diesen Header). Ich teste mit Chrome und Firefox und beide können die Kopfzeile nicht senden.

Gleiches Problem, ähnliche Lösung

Ich habe versucht herauszufinden, warum Google Chrome beim Besuch einer Website, die ich gerade entwickle, keine ETag -Kopfzeilen sendet. (Chrome 46.0.2490.71 m, obwohl ich nicht sicher bin, wie relevant die Version ist.)

Dies ist eine andere - wenn auch sehr ähnliche - Antwort als das letztlich zitierte OP (in einem Kommentar zur angenommenen Antwort), aber es behandelt das gleiche Problem:

Der Browser sendet den Header Content-type nicht in nachfolgenden Anfragen "wenn es sein sollte" (dh serverseitige Logik über PHP oder Ähnliches) wurde verwendet, um einen Header Content-type oder ETag in den zu senden erste Antwort).

Voraussetzungen

Wenn Sie ein selbstsigniertes TLS-Zertifikat verwenden, mit dem die Sperre in Chrome rot wird, ändert sich das Cache-Verhalten von Chrome. Bevor Sie versuchen, ein Problem dieser Art zu beheben, installieren Sie das selbstsignierte Zertifikat im effektiven vertrauenswürdigen Stammspeicher und starten Sie den Browser vollständig neu, wie in erklärt Ссылка .

1. Epiphanie: If-None-Match benötigt zuerst einen ETag vom Server

Ich habe ziemlich schnell gemerkt, dass Chrome (und wahrscheinlich die meisten oder alle anderen Browser) erst dann einen ETag -Header senden, wenn der Server hat bereits gesendet ein ETag Header als Antwort auf eine vorherige Anfrage. Logischerweise macht das vollkommenen Sinn; Wie könnte Chrome schließlich ETag senden, wenn ihm nie der Wert zugewiesen wurde?

Dies führte mich dazu, meine serverseitige Logik zu betrachten - insbesondere, wie Header gesendet werden, wenn der User-Agent die Antwort zwischenspeichern soll - um zu ermitteln, aus welchem ​​Grund der Header ETag nicht gesendet wird als Reaktion auf die allererste Anfrage von Chrome für die Ressource. Ich hatte eine berechnete Bemühung gemacht, den Header ETag in meine Anwendungslogik aufzunehmen.

Ich benutze PHP, daher ist der Kommentar von @ Mehran (der OP) auf mich gesprungen (er / sie sagt, dass das Aufrufen von Ctrl+F5 vor dem Senden der gewünschten cache-bezogenen Header das Problem löst).

Ehrlich gesagt, war ich skeptisch gegenüber dieser Lösung, weil a) ich ziemlich sicher war, dass PHP standardmäßig keine eigenen Header senden würde (und dies ist bei meiner Konfiguration nicht der Fall); und b) als ich 200 OK aufgerufen habe, kurz bevor ich meine benutzerdefinierten Caching-Header in PHP gesetzt habe, war der einzige Headersatz derjenige, den ich absichtlich genau oben gesetzt habe:

Um nichts zu verlieren, habe ich versucht, kurz vor dem Senden meiner benutzerdefinierten Header F5 aufzurufen. Und zu meiner Überraschung hat PHP plötzlich den Header 304 Not Modified gesendet!

2. Epiphany: Gzipping der Antwort ändert ihren Hash

Es traf mich dann wie eine Tüte Ziegel: Indem ich den Header 200 OK (from cache) in PHP angab, teilte ich NGINX (dem Webserver, den ich benutze) GZIP mit, sobald PHP es zurück an NGINX übergibt! Um es klar zu stellen, die Cache-Control: no-cache , die ich angegeben habe, war auf NGINX's Liste von Typen zu gzip.

Aus Gründen der Vollständigkeit sind meine NGINX GZIP-Einstellungen wie folgt und PHP ist über php-fpm mit NGINX verbunden:

Ich habe darüber nachgedacht, warum NGINX die Pragma: no-cache , die ich in PHP gesendet habe, entfernen könnte, wenn ein "gzip-fähiger" Inhaltstyp angegeben wurde, und kam zu einer jetzt offensichtlichen Antwort: weil NGINX den Antwortkörper modifiziert, den PHP zurückgibt wenn NGINX es gzips! Das macht durchaus Sinn. Es macht keinen Sinn, das 200 OK (from cache) zu senden, wenn es nicht mit der Antwort übereinstimmen wird, die zum Generieren verwendet wurde. Es ist ziemlich glatt, dass NGINX dieses Szenario so intelligent handhabt.

Ich weiß nicht, ob NGINX schon immer schlau genug war, Antwortstellen zu komprimieren, die unkomprimiert sind, aber %code% headers enthalten, aber das scheint hier zu geschehen.

Also, was ist die Lösung?

Also, was ist die Lösung, um %code% zurück in die Antwort zu bekommen? Führe das Gzipping in PHP durch, so dass NGINX sieht, dass die Antwort bereits komprimiert ist, und einfach weiterleitet, während der Header %code% intakt bleibt:

Nachdem ich diesen Aufruf vor dem Senden der Header und des Antworthauptteils hinzugefügt hatte, begann PHP, den %code% -Wert mit jeder Antwort zu senden. Ja!

Andere gelernte Lektionen

Hier sind einige interessante Leckerbissen aus meiner Forschung. Diese Informationen sind ziemlich praktisch, wenn Sie versuchen, eine serverseitige Caching-Implementierung zu testen, sei es in PHP oder in einer anderen Sprache.

Chrome und sein Developer Tools "Net" -Bereich verhalten sich anders als , je nachdem, wie die Anfrage initiiert wird .

Wenn die Anfrage "frisch" ist, indem Sie %code% drücken, sendet Chrome diese Header:

und der Server antwortet %code% .

Wenn die Anfrage nur mit %code% erfolgt, sendet Chrome diese Header:

und der Server antwortet %code% .

Wenn die Anfrage schließlich durch Klicken auf einen Link zu der Seite erfolgt, die Sie bereits sehen, oder in die Adressleiste von Chrome und drücken Sie die Eingabetaste, sendet Chrome diese Kopfzeilen:

und der Server antwortet %code% .

Obwohl dieses Verhalten anfangs etwas verwirrend ist, wenn Sie nicht wissen, wie es funktioniert, ist es ein ideales Verhalten, da es jedes mögliche Anfrage- / Antwortszenario sehr gründlich testen kann.

Am verwirrendsten ist es, dass Chrome automatisch die Header %code% und %code% in die ausgehende Anfrage einfügt , wenn tatsächlich Chrome die Antworten aus seinem Cache erfasst (wie in %code% Antwort).

Diese Erfahrung war für mich eher informativ und ich hoffe, dass andere diese Wertanalyse in der Zukunft finden.