NginX ignoriert ETag nicht

Question

Ich habe das Caching auf NginX (mit fastCGI) aktiviert.

Meine dynamischen Seiten ändern sich nicht sehr oft und ich möchte, dass sie im NginX-Cache gespeichert werden, solange sie sich nicht geändert haben (ich weiß, ich könnte stattdessen statische Seiten erstellen ... sagen wir mal.) aus historischen Gründen immer noch "dynamisch".

Wenn mein Backend-Server (Symfony 2) die Seite generiert, fügt er dem Antwortheader die ETAG + Max-Age-Parameter hinzu.

Ich möchte, dass der Browser die Seite für eine bestimmte Zeit im Cache behält. Wenn diese Zeit abgelaufen ist, möchte ich, dass der Browser einen "If-None-Match" HTTP HEAD mit der bereitgestellten ETAG sendet.

Wenn die Seite noch im Frontend-Cache vorhanden ist, möchte ich, dass NginX eine 304 Not Modified-Antwort sendet.

Wenn die Seite nicht mehr vorhanden ist (ich habe sie manuell gelöscht, wenn sie geändert wurde) möchte ich, dass NginX die Anfrage an den Backend-Server weiterleitet, der die HTTP 200-Antwort zurücksendet.

Ohne fastCGI Cache kann ich sehen, dass der Etag-Parameter im Antwort-Header (Debug-Panel von Firefox) vorhanden ist. Aber jedes Mal, wenn ich die Seite neu lade, sehe ich eine HTTP 200-Antwort anstelle einer HTTP 304-Antwort.

Mit fastCGI Cache verschwindet das ETag rein aus der ursprünglichen HTTP 200-Antwort. Und jedes Neuladen der Seite führt zu einer HTTP 200 reponse (obwohl X-Fastcgi-Cache Parameter sagen mir, das ist ein HIT)

Meine Fragen:

Warum der Browser eine GET-Anfrage sendet anstelle eines HEAD, obwohl ETag existiert?

Warum ETag verschwindet aus der Antwort, wenn ich FastCGI-Cache auf NginX aktivieren?

Ich bin ziemlich neu im Caching, damit ich etwas großes vermisse ....

Danke für Ihre Hilfe

Answer 1

Nach einer Untersuchung, ist der Grund für diese Probleme, dass Firefox den ETag als „schwach“ setzt, wenn die Seite in einem komprimierten Format empfangen wird. Dazu wird vor der ETag-Zeichenfolge ein zusätzliches "W /" hinzugefügt.

Dies führt symfony nicht den ETag zu erkennen als die gleiche wie die zuvor gesendet wird und damit die HTTP-200-Antwort anstelle von HTTP 304

Der Grund für diese zusätzlichen schwachen Informationen scheint zu sein, dass, wenn die ETag Wird vor der Komprimierung der Daten berechnet, kann dies zu einer ETag-Wert-Kollision und somit zu einer im Cache steckenden Seite führen, während sie erneuert werden sollte. Um zu verhindern, dass Firefox (sowie NginX zur Information) die schwachen (Ness) Informationen hinzufügt.

Hoffe, das kann jemand mit dem gleichen Problem helfen ....