Wie ermittelt WinInet was und wann zu cachen?

8

Ich experimentiere mit Caching zwischen meinem .NET-Client und Server. Ich sehe eine scheinbar zufällige Anzahl von Treffern auf einen Endpunkt, bevor WinInet entscheidet, das Ergebnis zwischenzuspeichern.

Der .NET-Client stellt Anfragen mit HttpWebRequest :

%Vor%

Der Server, der mit der ASP.net-Web-API implementiert wurde, legt diese CacheControl -Header fest:

%Vor%

Wenn ich einen Test-Kabelbaum mit einer Schaltfläche verwende, die die Anfrage an den Endpunkt sendet, kann ich sehen, dass, obwohl CacheIfAvailable verwendet wird, die Antwort nicht sofort zwischengespeichert wird . Wenn ich die Debug-Ausgabe auf meinem Server überprüfe, sehe ich, dass eine scheinbar zufällige Anzahl von Treffern ( oder wahrscheinlicher Trefferanzahl / verstrichene Zeit heuristics ) ausgelöst werden muss bevor die Anfrage schließlich zwischengespeichert wird. Wenn ich den Testknopf schnell wähle, fängt er nach etwa 10 Treffern an, zu cachen. Wenn ich alle 1 oder 2 Sekunden auf die Schaltfläche klicke, habe ich bis zu 25 Treffer gezählt, bevor ich die Caching-Funktion in aktiviere.

Dies ist die Antwort, die ich von Fiddler sehe:

%Vor%

Ich habe gelesen, dass HttpWebRequest WinInet zum Caching verwendet, also bin ich gespannt, wie WinInet bestimmt, wann etwas zwischengespeichert werden muss, genauer gesagt warum nicht Cache beim ersten Treffer?

    
Steve Dunn 28.11.2013, 18:16
quelle

1 Antwort

4

Ich benutze RequestCacheLevel.Default, sonst fand ich, dass Wininet gerne veraltete Antworten bedient.

Ich verwende auch must-revalidate nicht, da ich annehme, dass dies das Standardverhalten ist, sobald eine zwischengespeicherte Antwort veraltet ist.

Ich glaube, wenn Sie immer ein LastModifed oder Etag in Ihre Anfragen aufnehmen, erhalten Sie standardmäßig die lokale Kopie, bis sie abgelaufen ist (weil Sie Private und MaxAge eingestellt haben) und wenn sie abgelaufen ist, erhalten Sie vielleicht eine 304 zurück In diesem Fall wird es die lokale Kopie verwenden.

Nachdem Sie all dies gesagt haben, überprüfen Sie Ihre Antworten für den Header variieren. In vielen Fällen verhindert ein Vary-Header die Verwendung von Wininet, da der Header nicht korrekt unterstützt wird.

Verwenden Sie diesen Controller,

%Vor%

und dieser Client-Code,

%Vor%

Bei der Ausführung wird nur eine einzige Anforderung über das Netzwerk gestellt.

    
Darrel Miller 28.11.2013 19:36
quelle