Welche Reverse-Proxys unterstützen HTTP / 1.1 ETag- und If-None-Match-Header?

Ich entwickle ein Caching-System für eine E-Commerce-Plattform, die einen Reverse-Proxy für das Caching verwendet. Ich plane, die Ungültigmachung mithilfe geeigneter HTTP / 1.1-Header zu behandeln. Das heißt, ich werde ein ETag für die erste Generation des Inhalts festlegen und den ETag-Wert in der Anwendung zwischenspeichern. Der Cache-Control-Header gibt "must-revalidate" an, sodass der Proxy bei nachfolgenden Anforderungen mit dem ETag den If-None-Match-Header setzen sollte. Die Anwendung sucht nach dem zwischengespeicherten ETag-Wert und sendet, wenn er übereinstimmt, eine 304-Antwort, andernfalls generiert sie eine vollständige 200-Antwort.

Ich hatte gehofft, nginx verwenden zu können, aber ich kann nicht sicher sagen, dass es ETags unterstützt (Dokumente zeigen an, dass dies nicht der Fall ist, aber vielleicht sind sie veraltet?). Lack ist eine andere Option, aber ich bin auch hier nicht positiv.

Welche Reverse-Proxy-Server unterstützen ETags vollständig? Ich möchte, dass mehrere Versionen zwischengespeichert werden, damit ich beispielsweise Split-Tests durchführen kann, ohne den Cache deaktivieren zu müssen. Das heißt, HTTP / 1.1 gibt an, dass ein Client If-None-Match mit mehreren ETag-Werten senden kann und der Server antworten sollte, mit welchem ​​ETag (falls vorhanden) übereinstimmt. Wenn der Reverse-Proxy mehrere Kopien anstelle des zuletzt gesehenen Werts aufbewahrt und der Server bei jeder Anforderung angeben lässt, welche verwendet werden soll, ist dies ideal.

Ich habe gerade überprüft in Varnish Quellcode und obwohl sie unterstützen If-Modified-Sinceund If-None-MatchHeader, nicht unterstützt wird must-revalidatein Cache-Control. Die einzigen unterstützten Attribute in Cache-Controlsind max-ageund s-max-age.

Verweise:

• bin/varnishd/cache/cache_rfc2616.cin RFC2616_Do_Cond ()
• bin/varnishd/cache/cache_rfc2616.cin RFC2616_Ttl ()
• include/tbl/http_headers.h

Für nginx sind Module von Drittanbietern erforderlich, um ETag zu unterstützen. Und es gibt zwei davon.

• Statische ETags zum Zwischenspeichern von statischen Inhalten
• Dynamische ETags zum Zwischenspeichern von dynamischen Inhalten

Korrigieren Sie mich, wenn ich falsch liege, und ich weiß, dass dies ein alter Beitrag ist - aber ich möchte für neue Passanten einen Kommentar abgeben. Ich glaube, ein Reverse Proxy-Cache hilft nicht so viel, wie Sie möchten, wenn Sie ETags verwenden.

Validierungs-Caching-Mechanismen verwenden den Ursprungsserver, um zu überprüfen, ob das ETag (oder das Datum der letzten Änderung) in der Anforderung noch gültig ist (mit dem Ressourcen-Etag übereinstimmt oder nicht übereinstimmt, je nachdem, welcher Header verwendet wird oder geändert wurde / wurde seit dem auf Anfrage angegebenen Datum).

Dies bedeutet, dass ein Reverse-Proxy-Cache wie Varnish diese Anforderung weiterhin an den Ursprungsserver weiterleitet. Möglicherweise antwortet es mit der Anfrage, anstatt dass der Server sie bearbeitet, aber Sie haben den Roundtrip zum Ursprungsserver nicht gespeichert.

Browser können in jedem Fall Antworten zwischenspeichern und eine 304-Antwort verarbeiten. Daher ist der private Cache des Benutzers möglicherweise besser dafür geeignet als die Verwendung eines Reverse-Proxys (YMMV, insbesondere im Maßstab, und natürlich abhängig von Ihrem Anwendungsfall. Ich nicht Annahmen über Ihre Apps treffen möchten).

Aus der Spezifikation 13.3 :

Wenn ein Cache einen veralteten Eintrag hat, den er als Antwort auf die Anfrage eines Clients verwenden möchte, muss er zuerst beim Ursprungsserver (oder möglicherweise bei einem Zwischencache mit einer neuen Antwort) prüfen, ob sein zwischengespeicherter Eintrag noch verwendbar ist . Wir nennen dies "Validieren" des Cache-Eintrags. Da wir nicht den Aufwand für die erneute Übertragung der vollständigen Antwort bezahlen müssen, wenn der zwischengespeicherte Eintrag gut ist, und wir den Aufwand für eine zusätzliche Hin- und Rückfahrt nicht bezahlen möchten, wenn der zwischengespeicherte Eintrag ungültig ist, unterstützt das HTTP / 1.1-Protokoll die Verwendung von bedingten Methoden.

und dann Anmerkung 13.3.4 :

Ein HTTP / 1.1-Caching-Proxy darf nach Erhalt einer bedingten Anforderung, die sowohl ein Datum der letzten Änderung als auch ein oder mehrere Entitäts-Tags als Cache-Validatoren enthält, KEINE lokal zwischengespeicherte Antwort an den Client zurückgeben, es sei denn, diese zwischengespeicherte Antwort stimmt mit allen überein Bedingte Header-Felder in der Anforderung.

So kann Varnish eine Antwort für Sie zurückgeben, aber Sie haben immer noch einen Roundtrip zum Server. Wenn Sie einen App-Cache wie APC oder Memcache verwenden können, lohnt sich das möglicherweise noch für Sie. Das Validierungs-Caching ist jedoch im Allgemeinen besser für Bandbreiteneinsparungen als für Serverressourceneinsparungen.

Das Zwischenspeichern der Validierung kann am besten dem Client (Browser oder API-Code) überlassen werden.

Bei Verwendung des Ablaufmodells für das Caching leuchtet ein Reverse-Proxy-Cache wirklich. Auf diese Weise können Sie das Schlagen des Ursprungsservers insgesamt überspringen. Mit Expires, Cache-Control, Dateusw, ist die beste (wieder, IMO) Mechanismus für einen Reverse - Proxy - Cache als Cache kann die Antwort zurück, es ist nicht abgestanden vorausgesetzt, ohne jemals aus dem Ursprungsserver zu schlagen.

Sie können sich Apache TrafficServer ansehen , der anscheinend das hat, was Sie brauchen .

Bisher gibt es meines Erachtens noch keine Proxys, die diese HTTP-Spezifikation vollständig unterstützen. Vor ungefähr einem Jahr habe ich beschlossen, meine eigenen mit Node.js und MongoDb zu schreiben.

https://github.com/colinmollenhour/node-caching-proxy