Was bedeutet vary:accept-encoding?

Question

Das Google Page Speed-AddOn informiert mich:

Die folgenden öffentlich cachebaren, komprimierbaren Ressourcen sollten einen "Vary: Accept-Encoding" Header haben:
//einige .js und .css Dateien

Ich verstehe nicht, was das bedeutet. Ich habe diese Dateien bereits komprimiert wie folgt:

if (encodings.Contains("gzip") || encodings == "*")
{
    app.Response.Filter = new GZipStream(baseStream, CompressionMode.Compress);
    app.Response.AppendHeader("Content-Encoding", "gzip");
}

Und das scheint alles zu funktionieren. Warum ist es notwendig, Vary: Accept-Encoding zu haben?

Answer 1

Es erlaubt dem Cache, je nachdem, ob der Browser GZIP-Codierung anfordert oder nicht, verschiedene zwischengespeicherte Versionen der Seite bereitzustellen. Der Vary-Header weist den Cache an, eine andere Version der Seite zu speichern, wenn eine Variation im angegebenen Header vorliegt.

Derzeit wird möglicherweise eine (möglicherweise komprimierte) Kopie der Seite im Cache gespeichert. Nehmen wir an, es handelt sich um die komprimierte Version: Wenn jemand die Ressource anfordert, jedoch keine gzip-Codierung unterstützt, wird ihm der falsche Inhalt bereitgestellt.

Answer 2

Vary: Accept-Encoding informiert das Verhalten des Servers in Bezug auf das Zwischenspeichern der Darstellung der angeforderten Ressource. Wenn eine neue Anfrage für eine zuvor zwischengespeicherte Ressource empfangen wird, wird sie aus dem Cache bedient, es sei denn, der Accept-Encoding-Header der neuen Anfrage unterscheidet sich von der zuvor zwischengespeicherten Darstellung, an diesem Punkt wird die Anfrage als neue Anfrage behandelt und nicht aus dem Cache bedient.

** BEARBEITEN ** Wie spender darauf hinweist - wenn Sie eine komprimierte Datei aus dem Cache ausliefern und der Client Ihren Komprimierungsmechanismus nicht akzeptiert, erhalten sie eine Seite mit Datenmüll, also ja, es ist notwendig. Sie würden den Unterschied nicht unbedingt durch normales Testen bemerken.

Siehe http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.44 und http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.3