Warum HttpCacheability.Private unterdrücken ETags?

Question

Während das schreiben eines benutzerdefinierten IHttpHandler stieß ich auf ein Verhalten, das ich nicht erwartet hatte, über die HttpCachePolicy Objekt.

Mein handler berechnet und setzt ein entity-tag (mit der SetETag Methode auf die HttpCachePolicy im Zusammenhang mit der aktuellen response-Objekt).Wenn ich den cache-control, um die öffentliche Verwendung der SetCacheability Methode alles funktioniert wie ein Zauber, und der server sendet entlang der e-tag-header.Wenn ich ihn an die private e-tag-header unterdrückt wird.

Vielleicht habe ich einfach nicht sah schwer genug, aber ich habe nicht gesehen, was in der HTTP/1.1 Spezifikation rechtfertigen würden, dass dieses Verhalten.Warum würden Sie nicht wollen, zu senden E-Tag-Browser noch das Verbot proxies speichern Sie die Daten?

using System;
using System.Web;

public class Handler : IHttpHandler {
    public void ProcessRequest (HttpContext ctx) {
        ctx.Response.Cache.SetCacheability(HttpCacheability.Private);
        ctx.Response.Cache.SetETag("\"static\"");
        ctx.Response.ContentType = "text/plain";
        ctx.Response.Write("Hello World");
    }

    public bool IsReusable { get { return true; } }
}

Zurück

Cache-Control: private
Content-Type: text/plain; charset=utf-8
Content-Length: 11

Aber wenn wir es ändern, um die öffentlichkeit werde zurückkehren

Cache-Control: public
Content-Type: text/plain; charset=utf-8
Content-Length: 11
Etag: "static"

Ich habe dies auf der ASP.NET development server und IIS6 bisher mit dem gleichen Ergebnis.Auch bin ich nicht explizit gesetzt werden, ETag mit

Response.AppendHeader("ETag", "static")

Update:Es ist möglich, hängen Sie den ETag-header manuell beim laufen in IIS7, ich vermute, dies ist verursacht durch die enge integration zwischen ASP.NET und die IIS7-pipeline.

Klärung:Es ist eine lange Frage, aber die Kern-Frage ist diese: warum ASP.NET tun, wie kann ich es umgehen und sollte ich?

Update:Ich werde akzeptieren Tony Antwort da es im wesentlichen korrekt (gehen Tony!).Ich fand, dass, wenn Sie möchten, zu emulieren, die HttpCacheability.Private voll Sie können die cachefähigkeit zu Cachefähigkeit, aber Sie haben auch call-cache.SetOmitVaryStar(true), andernfalls wird der Zwischenspeicher hinzufügen Vary:* - header an den Ausgang, und das wollen Sie nicht.Ich werde Bearbeiten Sie, dass in der Antwort, wenn ich Berechtigungen Bearbeiten (oder wenn dieser Tony vielleicht könnten Sie Bearbeiten Ihre Antwort, dass Sie diese nennen?)

Answer 1

Ich denke, Sie müssen zu verwenden HttpCacheability.Cachefähigkeit

Das sollten Sie cache-control:private in den Kopf und lassen Sie legen Sie einen ETag.

Die Dokumentation muss ein bisschen besser werden.

Edit: Markus fand, dass Sie auch call-cache.SetOmitVaryStar(true), ansonsten der cache wird fügen Sie Variieren:* header an den Ausgang, und das wollen Sie nicht.

Answer 2

Leider, wenn Sie Blick auf System.Web.HttpCachePolicy.UpdateCachedHeaders() in .NET Reflektor sieht man, dass es eine if-Anweisung, insbesondere die überprüfung, dass die Cachefähigkeit ist nicht Privat, bevor Sie einen ETag-Zeug.In jedem Fall, ich habe immer gefunden, dass Last-Modified/If-Modified-Since funktioniert gut für unsere Daten und ist ein wenig einfacher zu überwachen, in Fiddler sowieso.

Answer 3

Wenn Sie wie ich sind Sie unglücklich mit dem workaround hier erwähnten mit Cachefähigkeit.Cachefähigkeit, und Sie wirklich wollen, um die Nutzung der Privaten statt - vielleicht, weil Sie die Anpassung Seiten einzeln für Benutzer, und es macht keinen Sinn, den cache auf dem server - zumindest dann .NET 3.5 können Sie festlegen, ETag durch Reaktion.Header.Hinzufügen und dies funktioniert gut.

N. B.wenn Sie dies tun, die Sie implementieren müssen, um den Vergleich von der client-Header selbst und die HTTP-Antwort 304 handling - nicht sicher, ob .NET übernimmt dies für Sie, unter normalen Umständen,.