Zwischenspeichern von Antworten in ASP.NET Core

Von Rick Anderson und Kirk Larkin

Anzeigen oder Herunterladen von Beispielcode (Vorgehensweise zum Herunterladen)

Die Zwischenspeicherung von Antworten reduziert die Anzahl der Anforderungen, die ein Client oder Proxy an einen Webserver stellt. Das Zwischenspeichern von Antworten reduziert auch die Arbeitsaufwand, die der Webserver ausführt, um eine Antwort zu generieren. Das Zwischenspeichern von Antworten wird in Headern festgelegt.

Das ResponseCache-Attribut legt Header für das Zwischenspeichern von Antworten fest. Clients und Zwischenproxys sollten die Header für das Zwischenspeichern von Antworten gemäß der HTTP 1.1 Caching-Spezifikation berücksichtigen.

Verwenden Sie für die serverseitige Zwischenspeicherung, die der HTTP 1.1-Zwischenspeicherungsspezifikation entspricht, Middleware für das Zwischenspeichern von Antworten. Die Middleware kann die Eigenschaften verwenden, um das ResponseCacheAttribute serverseitige Cacheverhalten zu beeinflussen.

Die Middleware für die Zwischenspeicherung von Antworten:

  • Ermöglicht das Zwischenspeichern von Serverantworten basierend auf HTTP-Cacheheadern. Implementiert die Standardmäßige HTTP-Cachesemantik. Caches, die auf HTTP-Cacheheadern wie Proxys basieren.
  • Ist in der Regel nicht vorteilhaft für Benutzeroberflächen-Apps wie Razor Pages, da Browser in der Regel Anforderungsheader festlegen, die das Zwischenspeichern verhindern. Die Zwischenspeicherung der Ausgabe wird für die nächste Version von ASP.NET Core in Betracht gezogen, von der Benutzeroberflächen-Apps profitieren. Beim Zwischenspeichern der Ausgabe entscheidet die Konfiguration, was unabhängig von HTTP-Headern zwischengespeichert werden soll. Weitere Informationen finden Sie in diesem GitHub-Issue.
  • Kann für öffentliche GET- oder HEAD-API-Anforderungen von Clients vorteilhaft sein, bei denen die Bedingungen für die Zwischenspeicherung erfüllt sind.

Verwenden Sie Fiddler, Postman oder ein anderes Tool, das Anforderungsheader explizit festlegen kann. Das explizite Festlegen von Headern wird zum Testen der Zwischenspeicherung bevorzugt. Weitere Informationen finden Sie unter Problembehandlung.

HTTP-basiertes Zwischenspeichern von Antworten

Die HTTP 1.1-Cachingspezifikation beschreibt das Verhalten von Internetcaches. Der primäre HTTP-Header, der für das Zwischenspeichern verwendet wird, ist Cache-Control, der zum Angeben von Cachedirektiven verwendet wird. Die -Direktiven steuern das Verhalten beim Zwischenspeichern, wenn Anforderungen ihren Weg von Clients zu Servern und als Antworten von Servern zurück zu Clients herstellen. Anforderungen und Antworten werden über Proxyserver übertragen, und Proxyserver müssen auch der HTTP 1.1-Cachingspezifikation entsprechen.

Allgemeine Cache-Control Anweisungen sind in der folgenden Tabelle dargestellt.

Anweisung Aktion
public Ein Cache kann die Antwort speichern.
private Die Antwort darf nicht von einem freigegebenen Cache gespeichert werden. Ein privater Cache kann die Antwort speichern und wiederverwenden.
max-age Der Client akzeptiert keine Antwort, deren Alter größer als die angegebene Anzahl von Sekunden ist. Beispiele: max-age=60 (60 Sekunden), max-age=2592000 (1 Monat)
kein Cache Bei Anforderungen: Ein Cache darf keine gespeicherte Antwort verwenden, um die Anforderung zu erfüllen. Der Ursprungsserver generiert die Antwort für den Client neu, und die Middleware aktualisiert die gespeicherte Antwort im Cache.

Bei Antworten: Die Antwort darf nicht für eine nachfolgende Anforderung ohne Überprüfung auf dem Ursprungsserver verwendet werden.
no-store Bei Anforderungen: Ein Cache darf die Anforderung nicht speichern.

Bei Antworten: Ein Cache darf keinen Teil der Antwort speichern.

Andere Cacheheader, die beim Zwischenspeichern eine Rolle spielen, sind in der folgenden Tabelle dargestellt.

Header Funktion
Age (Alter) Eine Schätzung der Zeitspanne in Sekunden, seit die Antwort auf dem Ursprungsserver generiert oder erfolgreich überprüft wurde.
Läuft ab Die Zeit, nach der die Antwort als veraltet betrachtet wird.
Pragma Ist aus Gründen der Abwärtskompatibilität mit HTTP/1.0-Caches zum Festlegen no-cache des Verhaltens vorhanden. Wenn der Cache-Control Header vorhanden ist, wird der Pragma Header ignoriert.
Variieren Gibt an, dass eine zwischengespeicherte Antwort nur gesendet werden darf, wenn alle Vary Headerfelder sowohl in der ursprünglichen Anforderung der zwischengespeicherten Antwort als auch in der neuen Anforderung übereinstimmen.

Http-basierte Zwischenspeicherung beachtet Anforderungen Cache-Control-Direktiven.

Die HTTP 1.1-Cachingspezifikation für den Cache-Control-Header erfordert einen Cache, um einen gültigen Cache-Control Header zu erfüllen, der vom Client gesendet wird. Ein Client kann Anforderungen mit einem no-cache Headerwert stellen und erzwingen, dass der Server für jede Anforderung eine neue Antwort generiert.

Es ist sinnvoll, Clientanforderungsheader Cache-Control immer zu berücksichtigen, wenn Sie das Ziel der HTTP-Zwischenspeicherung in Betracht ziehen. Gemäß der offiziellen Spezifikation soll das Zwischenspeichern die Latenz und den Netzwerkaufwand für die Erfüllung von Anforderungen über ein Netzwerk von Clients, Proxys und Servern reduzieren. Dies ist nicht unbedingt eine Möglichkeit, die Last auf einem Ursprungsserver zu steuern.

Bei Verwendung der Middleware für das Zwischenspeichern von Antworten gibt es keine Kontrolle durch Entwickler über dieses Zwischenspeicherverhalten, da die Middleware der offiziellen Cachespezifikation entspricht. Die Unterstützung der Ausgabezwischenspeicherung zur besseren Steuerung der Serverauslastung ist ein Entwurf für eine zukünftige Version von ASP.NET Core. Weitere Informationen finden Sie unter Hinzufügen von Unterstützung für das Zwischenspeichern von Ausgaben (dotnet/aspnetcore #27387).

ResponseCache-Attribut

Gibt ResponseCacheAttribute die Parameter an, die zum Festlegen geeigneter Header beim Zwischenspeichern von Antworten erforderlich sind.

Warnung

Deaktivieren Sie die Zwischenspeicherung für Inhalte, die Informationen für authentifizierte Clients enthalten. Das Zwischenspeichern sollte nur für Inhalte aktiviert werden, die sich nicht basierend auf der Identität eines Benutzers oder der Anmeldung eines Benutzers ändern.

VaryByQueryKeys variiert die gespeicherte Antwort durch die Werte der angegebenen Liste von Abfrageschlüsseln. Wenn ein einzelner Wert von * angegeben wird, variiert die Middleware die Antworten durch alle Parameter der Anforderungsabfragezeichenfolge.

Middleware für das Zwischenspeichern von Antworten muss aktiviert sein, um die VaryByQueryKeys -Eigenschaft festzulegen. Andernfalls wird eine Laufzeitausnahme ausgelöst. Es gibt keinen entsprechenden HTTP-Header für die VaryByQueryKeys -Eigenschaft. Die -Eigenschaft ist ein HTTP-Feature, das von middleware für das Zwischenspeichern von Antworten verarbeitet wird. Damit die Middleware eine zwischengespeicherte Antwort bedienen kann, müssen die Abfragezeichenfolge und der Abfragezeichenfolgenwert mit einer vorherigen Anforderung übereinstimmen. Betrachten Sie beispielsweise die Reihenfolge der Anforderungen und Ergebnisse, die in der folgenden Tabelle angezeigt werden:

Anforderung Zurückgegeben von
http://example.com?key1=value1 Server
http://example.com?key1=value1 Middleware
http://example.com?key1=NewValue Server

Die erste Anforderung wird vom Server zurückgegeben und in Middleware zwischengespeichert. Die zweite Anforderung wird von middleware zurückgegeben, da die Abfragezeichenfolge mit der vorherigen Anforderung übereinstimmt. Die dritte Anforderung befindet sich nicht im Middlewarecache, da der Wert der Abfragezeichenfolge nicht mit einer vorherigen Anforderung übereinstimmt.

Wird ResponseCacheAttribute verwendet, um (über IFilterFactory) eine Microsoft.AspNetCore.Mvc.Internal.ResponseCacheFilterzu konfigurieren und zu erstellen. Führt ResponseCacheFilter die Aktualisierung der entsprechenden HTTP-Header und -Features der Antwort durch. Der Filter:

  • Entfernt alle vorhandenen Header für Vary, Cache-Controlund Pragma.
  • Schreibt die entsprechenden Header basierend auf den in ResponseCacheAttributeder festgelegten Eigenschaften.
  • Aktualisiert die HTTP-Funktion zum Zwischenspeichern von Antworten, wenn VaryByQueryKeys festgelegt ist.

Variieren

Dieser Header wird nur geschrieben, wenn die VaryByHeader -Eigenschaft festgelegt ist. Die -Eigenschaft, die auf den Wert der Vary Eigenschaft festgelegt ist. Im folgenden Beispiel wird die VaryByHeader -Eigenschaft verwendet:

[ApiController]
public class TimeController : ControllerBase
{
    [Route("api/[controller]")]
    [HttpGet]
    [ResponseCache(VaryByHeader = "User-Agent", Duration = 30)]
    public ContentResult GetTime() => Content(
                      DateTime.Now.Millisecond.ToString());

Zeigen Sie die Antwortheader mit Fiddler oder einem anderen Tool an. Die Antwortheader umfassen Folgendes:

Cache-Control: public,max-age=30
Vary: User-Agent

Der vorangehende Code erfordert das Hinzufügen der Middlewaredienste für das Zwischenspeichern von Antworten zur Dienstsammlung und konfiguriert die App für die Verwendung der Middleware AddResponseCaching mit der Erweiterungsmethode UseResponseCaching .

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers();
builder.Services.AddResponseCaching();

var app = builder.Build();

app.UseHttpsRedirection();

// UseCors must be called before UseResponseCaching
//app.UseCors();

app.UseResponseCaching();

app.UseAuthorization();

app.MapControllers();

app.Run();

NoStore und Location.None

NoStore überschreibt die meisten anderen Eigenschaften. Wenn diese Eigenschaft auf festgelegt ist true, wird der Cache-Control Header auf festgelegt no-store. Wenn Location auf festgelegt ist None:

  • Für Cache-Control ist no-store,no-cache festgelegt.
  • Für Pragma ist no-cache festgelegt.

Wenn NoStore ist und Locationfalse istNone, Cache-Controlsind und Pragma auf festgelegtno-cache.

NoStore wird für Fehlerseiten in der true Regel auf festgelegt. Im Folgenden werden Antwortheader erzeugt, die den Client anweisen, die Antwort nicht zu speichern.

[Route("api/[controller]/ticks")]
[HttpGet]
[ResponseCache(Duration = 0, Location = ResponseCacheLocation.None, NoStore = true)]
public ContentResult GetTimeTicks() => Content(
                  DateTime.Now.Ticks.ToString());

Der vorangehende Code enthält die folgenden Header in der Antwort:

Cache-Control: no-store,no-cache
Pragma: no-cache

Standort und Dauer

Um das Zwischenspeichern zu aktivieren, Duration muss auf einen positiven Wert festgelegt werden und LocationAny entweder (Standard) oder sein Client. Das Framework legt den Header Cache-Control auf den Speicherortwert gefolgt von der max-age der Antwort fest.

LocationDie Optionen von und Any werden Client in Headerwerte Cache-Control von public bzw private. übersetzt. Wie im Abschnitt NoStore und Location.None angegeben , Location legt die Einstellung auf None sowohl die Header Cache-Control als Pragma auch auf fest no-cache.

Location.Any(Cache-Control festgelegt auf public) gibt an, dass der Client oder ein beliebiger Zwischenproxy den Wert zwischenspeichern kann, einschließlich Middleware für das Zwischenspeichern von Antworten.

Location.Client (Cache-Control festgelegt auf private) gibt an , dass nur der Client den Wert zwischenspeichern darf. Der Wert sollte nicht zwischengespeichert werden, einschließlich Middleware für das Zwischenspeichern von Antworten.

Cachesteuerungsheader bieten Clients und zwischengeschalteten Proxys Anleitungen dazu, wann und wie Antworten zwischengespeichert werden. Es gibt keine Garantie, dass Clients und Proxys die HTTP 1.1-Cachingspezifikation erfüllen. Die Middleware für das Zwischenspeichern von Antworten folgt immer den Cacheregeln, die in der Spezifikation festgelegt sind.

Das folgende Beispiel zeigt die Header, die durch Festlegen und Belässt Duration des Standardwerts erzeugt Location werden:

[Route("api/[controller]/ms")]
[HttpGet]
[ResponseCache(Duration = 10, Location = ResponseCacheLocation.Any, NoStore = false)]
public ContentResult GetTimeMS() => Content(
                  DateTime.Now.Millisecond.ToString());

Der vorangehende Code enthält die folgenden Header in der Antwort:

Cache-Control: public,max-age=10

Cacheprofile

Anstatt die Einstellungen des Antwortcaches für viele Controlleraktionsattribute zu duplizieren, können Cacheprofile beim Einrichten von MVC/Pages als Optionen konfiguriertRazor werden. Werte, die in einem Cacheprofil gefunden ResponseCacheAttribute werden, auf das verwiesen wird, werden als Standardwerte von verwendet und von allen Eigenschaften überschrieben, die für das Attribut angegeben sind.

Das folgende Beispiel zeigt ein 30-Sekunden-Cacheprofil:

using Microsoft.AspNetCore.Mvc;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCaching();
builder.Services.AddControllers(options =>
{
    options.CacheProfiles.Add("Default30",
        new CacheProfile()
        {
            Duration = 30
        });
});

var app = builder.Build();

app.UseHttpsRedirection();

// UseCors must be called before UseResponseCaching
//app.UseCors();

app.UseResponseCaching();

app.UseAuthorization();

app.MapControllers();

app.Run();

Der folgende Code verweist auf das Default30 Cacheprofil:

[ApiController]
[ResponseCache(CacheProfileName = "Default30")]
public class Time2Controller : ControllerBase
{
    [Route("api/[controller]")]
    [HttpGet]
    public ContentResult GetTime() => Content(
                      DateTime.Now.Millisecond.ToString());

    [Route("api/[controller]/ticks")]
    [HttpGet]
    public ContentResult GetTimeTicks() => Content(
                      DateTime.Now.Ticks.ToString());
}

Die resultierende Headerantwort des Cacheprofils Default30 umfasst Folgendes:

Cache-Control: public,max-age=30

Das [ResponseCache] -Attribut kann auf:

  • Razor Pages: Attribute können nicht auf Handlermethoden angewendet werden. Browser, die mit Benutzeroberflächen-Apps verwendet werden, verhindern das Zwischenspeichern von Antworten.
  • MVC-Controller.
  • MVC-Aktionsmethoden: Attribute auf Methodenebene überschreiben die in Attributen auf Klassenebene angegebenen Einstellungen.

Der folgende Code wendet das - [ResponseCache] Attribut auf Controller- und Methodenebene an:

[ApiController]
[ResponseCache(VaryByHeader = "User-Agent", Duration = 30)]
public class Time4Controller : ControllerBase
{
    [Route("api/[controller]")]
    [HttpGet]
    public ContentResult GetTime() => Content(
                      DateTime.Now.Millisecond.ToString());

    [Route("api/[controller]/ticks")]
    [HttpGet]
    public ContentResult GetTimeTicks() => Content(
                  DateTime.Now.Ticks.ToString());

    [Route("api/[controller]/ms")]
    [HttpGet]
    [ResponseCache(Duration = 10, Location = ResponseCacheLocation.Any, NoStore = false)]
    public ContentResult GetTimeMS() => Content(
                      DateTime.Now.Millisecond.ToString());
}

Zusätzliche Ressourcen

Anzeigen oder Herunterladen von Beispielcode (Vorgehensweise zum Herunterladen)

Das Zwischenspeichern von Antworten reduziert die Anzahl der Anforderungen, die ein Client oder Proxy an einen Webserver sendet. Das Zwischenspeichern von Antworten reduziert auch den Arbeitsaufwand, den der Webserver ausführt, um eine Antwort zu generieren. Das Zwischenspeichern von Antworten wird durch Header gesteuert, die angeben, wie Client, Proxy und Middleware Antworten zwischenspeichern möchten.

Der [ResponseCache] nimmt am Festlegen von Antwortzwischenspeicherungsheadern teil. Clients und Zwischenproxies sollten die Header für das Zwischenspeichern von Antworten gemäß der HTTP 1.1-Zwischenspeicherungsspezifikation verwenden.

Verwenden Sie für das serverseitige Zwischenspeichern, das der HTTP 1.1-Zwischenspeicherungsspezifikation entspricht, Middleware für das Zwischenspeichern von Antworten. Die Middleware kann die Eigenschaften verwenden [ResponseCache] , um serverseitige Zwischenspeicherungsheader festlegen.

HTTP-basiertes Zwischenspeichern von Antworten

Die HTTP 1.1-Zwischenspeicherungsspezifikation beschreibt das Verhalten von Internetcaches. Der primäre HTTP-Header, der für das Zwischenspeichern verwendet wird, ist Cache-Control, das zum Angeben von Cache-Direktiven verwendet wird. Die -Anweisungen steuern das Verhalten beim Zwischenspeichern, wenn Anforderungen ihren Weg von Clients zu Servern und antworten von Servern zurück zu Clients finden. Anforderungen und Antworten werden über Proxyserver übertragen, und Proxyserver müssen auch der HTTP 1.1-Cachingspezifikation entsprechen.

Allgemeine Cache-Control Anweisungen sind in der folgenden Tabelle dargestellt.

Anweisung Aktion
public Die Antwort kann in einem Cache gespeichert werden.
private Die Antwort darf nicht von einem freigegebenen Cache gespeichert werden. Ein privater Cache kann die Antwort speichern und wiederverwenden.
max-age Der Client akzeptiert keine Antwort, deren Alter größer als die angegebene Anzahl von Sekunden ist. Beispiele: max-age=60 (60 Sekunden), max-age=2592000 (1 Monat)
no-cache Bei Anforderungen: Ein Cache darf keine gespeicherte Antwort verwenden, um die Anforderung zu erfüllen. Der Ursprungsserver generiert die Antwort für den Client neu, und die Middleware aktualisiert die gespeicherte Antwort im Cache.

Bei Antworten: Die Antwort darf nicht für eine nachfolgende Anforderung ohne Überprüfung auf dem Ursprungsserver verwendet werden.
no-store Bei Anforderungen: Ein Cache darf die Anforderung nicht speichern.

Bei Antworten: Ein Cache darf keinen Teil der Antwort speichern.

Andere Cacheheader, die beim Zwischenspeichern eine Rolle spielen, sind in der folgenden Tabelle aufgeführt.

Header Funktion
Age (Alter) Eine Schätzung der Zeit in Sekunden, seit die Antwort auf dem Ursprungsserver generiert oder erfolgreich überprüft wurde.
Läuft ab Die Zeit, nach der die Antwort als veraltet gilt.
Pragma Ist für Abwärtskompatibilität mit HTTP/1.0-Caches zum Festlegen des Verhaltens no-cache vorhanden. Wenn der Cache-Control Header vorhanden ist, wird Pragma der Header ignoriert.
Variieren Gibt an, dass eine zwischengespeicherte Vary Antwort nur gesendet werden darf, wenn alle Headerfelder sowohl in der ursprünglichen Anforderung der zwischengespeicherten Antwort als auch in der neuen Anforderung übereinstimmen.

Http-basiertes Zwischenspeichern beachtet anforderungsbasierte Cache-Control-

Die HTTP 1.1-ZwischenspeicherungsspezifikationCache-Control für den Cache-Control-Header erfordert einen Cache, um einen gültigen Header zu erfüllen, der vom Client gesendet wird. Ein Client kann Anforderungen mit einem Headerwert no-cache senden und erzwingen, dass der Server für jede Anforderung eine neue Antwort generiert.

Die Berücksichtigung von Clientanforderungsheadern Cache-Control ist sinnvoll, wenn Sie das Ziel der HTTP-Zwischenspeicherung berücksichtigen. Gemäß der offiziellen Spezifikation soll die Zwischenspeicherung die Latenz und den Netzwerkaufwand für die Erfüllung von Anforderungen über ein Netzwerk von Clients, Proxys und Servern reduzieren. Es ist nicht notwendigerweise eine Möglichkeit, die Last auf einem Ursprungsserver zu steuern.

Bei Verwendung der Middleware für das Zwischenspeichern von Antworten haben Entwickler keine Kontrolle über dieses Cachingverhalten, da die Middleware der offiziellen Cachingspezifikation entspricht. Die Unterstützung der Ausgabezwischenspeicherung zur besseren Steuerung der Serverauslastung ist ein Entwurfvorschlag für eine zukünftige Version ASP.NET Core. Weitere Informationen finden Sie unter Hinzufügen von Unterstützung für das Zwischenspeichern von Ausgaben (dotnet/aspnetcore #27387).

Andere Cachetechnologie in ASP.NET Core

In-Memory-Caching

Beim Zwischenspeichern im Arbeitsspeicher wird Serverspeicher zum Speichern zwischengespeicherter Daten verwendet. Diese Art der Zwischenspeicherung eignet sich für einen einzelnen Server oder mehrere Server mit Sitzungsaffinität. Sitzungsaffinität wird auch als "Sticky Sessions" bezeichnet. Sitzungsaffinität bedeutet, dass die Anforderungen von einem Client zur Verarbeitung immer an denselben Server weitergeleitet werden.

Weitere Informationen finden Sie unter Cache in-Memory in ASP.NET Core und Troubleshoot Azure Application Gateway session affinity issues (Beheben von Problemen mit Azure Application Gateway Sitzungsaffinität).

Verteilter Cache

Verwenden Sie einen verteilten Cache, um Daten im Arbeitsspeicher zu speichern, wenn die App in einer Cloud- oder Serverfarm gehostet wird. Der Cache wird von den Servern gemeinsam genutzt, die Anforderungen verarbeiten. Ein Client kann eine Anforderung übermitteln, die von einem beliebigen Server in der Gruppe verarbeitet wird, wenn zwischengespeicherte Daten für den Client verfügbar sind. ASP.NET Core funktioniert mit verteilten Caches für SQL Server, Redis und NCache.

Weitere Informationen finden Sie unter Verteiltes Zwischenspeichern in ASP.NET Core.

Cache-Taghilfsprogramm

Zwischenspeichern des Inhalts aus einer MVC-Ansicht oder Razor -Seite mit dem Cachetaghilfs-Hilfgeber. Das Cache-Taghilfsmodul verwendet die Zwischenspeicherung im Arbeitsspeicher, um Daten zu speichern.

Weitere Informationen finden Sie unter Cache Tag Helper in ASP.NET Core MVC.

Taghilfsprogramm für verteilten Cache

Zwischenspeichern des Inhalts aus einer MVC-Ansicht oder Razor -Seite in verteilten Cloud- oder Webfarmszenarien mit dem Taghilfs-Tool für verteilten Cache. Das Taghilfs-Tool für verteilte Caches verwendet SQL Server, Redis oder NCache, um Daten zu speichern.

Weitere Informationen finden Sie unter Distributed Cache Tag Helper in ASP.NET Core.

ResponseCache-Attribut

Gibt ResponseCacheAttribute die Parameter an, die zum Festlegen geeigneter Header beim Zwischenspeichern von Antworten erforderlich sind.

Warnung

Deaktivieren Sie die Zwischenspeicherung für Inhalte, die Informationen für authentifizierte Clients enthalten. Das Zwischenspeichern sollte nur für Inhalte aktiviert werden, die sich nicht basierend auf der Identität eines Benutzers oder der Anmeldung eines Benutzers ändern.

VaryByQueryKeys variiert die gespeicherte Antwort durch die Werte der angegebenen Liste von Abfrageschlüsseln. Wenn ein einzelner Wert von * angegeben wird, variiert die Middleware die Antworten durch alle Parameter der Anforderungsabfragezeichenfolge.

Middleware für das Zwischenspeichern von Antworten muss aktiviert sein, um die VaryByQueryKeys -Eigenschaft festzulegen. Andernfalls wird eine Laufzeitausnahme ausgelöst. Es gibt keinen entsprechenden HTTP-Header für die VaryByQueryKeys -Eigenschaft. Die -Eigenschaft ist ein HTTP-Feature, das von middleware für das Zwischenspeichern von Antworten verarbeitet wird. Damit die Middleware eine zwischengespeicherte Antwort bedienen kann, müssen die Abfragezeichenfolge und der Abfragezeichenfolgenwert mit einer vorherigen Anforderung übereinstimmen. Betrachten Sie beispielsweise die Reihenfolge der Anforderungen und Ergebnisse in der folgenden Tabelle.

Anforderung Ergebnis
http://example.com?key1=value1 Wird vom Server zurückgegeben.
http://example.com?key1=value1 Von Middleware zurückgegeben.
http://example.com?key1=value2 Wird vom Server zurückgegeben.

Die erste Anforderung wird vom Server zurückgegeben und in Middleware zwischengespeichert. Die zweite Anforderung wird von middleware zurückgegeben, da die Abfragezeichenfolge mit der vorherigen Anforderung übereinstimmt. Die dritte Anforderung befindet sich nicht im Middlewarecache, da der Wert der Abfragezeichenfolge nicht mit einer vorherigen Anforderung übereinstimmt.

Wird ResponseCacheAttribute verwendet, um (über IFilterFactory) eine Microsoft.AspNetCore.Mvc.Internal.ResponseCacheFilterzu konfigurieren und zu erstellen. Führt ResponseCacheFilter die Aktualisierung der entsprechenden HTTP-Header und -Features der Antwort durch. Der Filter:

  • Entfernt alle vorhandenen Header für Vary, Cache-Controlund Pragma.
  • Schreibt die entsprechenden Header basierend auf den in ResponseCacheAttributeder festgelegten Eigenschaften.
  • Aktualisiert die HTTP-Funktion zum Zwischenspeichern von Antworten, wenn VaryByQueryKeys festgelegt ist.

Variieren

Dieser Header wird nur geschrieben, wenn die VaryByHeader -Eigenschaft festgelegt ist. Die -Eigenschaft, die auf den Wert der Vary Eigenschaft festgelegt ist. Im folgenden Beispiel wird die VaryByHeader -Eigenschaft verwendet:

[ResponseCache(VaryByHeader = "User-Agent", Duration = 30)]
public class Cache1Model : PageModel
{

Zeigen Sie mithilfe der Beispiel-App die Antwortheader mit den Netzwerktools des Browsers an. Die folgenden Antwortheader werden mit der Cache1-Seitenantwort gesendet:

Cache-Control: public,max-age=30
Vary: User-Agent

NoStore und Location.None

NoStore überschreibt die meisten anderen Eigenschaften. Wenn diese Eigenschaft auf truefestgelegt ist, wird der Cache-Control Header auf no-storefestgelegt. Wenn Location auf Nonefestgelegt ist:

  • Für Cache-Control ist no-store,no-cache festgelegt.
  • Für Pragma ist no-cache festgelegt.

Wenn NoStore ist false und Location ist None, Cache-Controlwerden und Pragma auf no-cachefestgelegt.

NoStore ist in der Regel für Fehlerseiten auf true festgelegt. Die Cache2-Seite in der Beispiel-App erzeugt Antwortheader, die den Client anweisen, die Antwort nicht zu speichern.

[ResponseCache(Duration = 0, Location = ResponseCacheLocation.None, NoStore = true)]
public class Cache2Model : PageModel
{

Die Beispiel-App gibt die Seite Cache2 mit den folgenden Headern zurück:

Cache-Control: no-store,no-cache
Pragma: no-cache

Standort und Dauer

Um das Zwischenspeichern zu aktivieren, Duration muss auf einen positiven Wert festgelegt werden und Location entweder Any (Standard) oder Clientsein. Das Framework legt den Cache-Control Header auf den Speicherortwert fest, gefolgt von der max-age der Antwort.

Locationdie Optionen von Any und Client werden in Cache-Control Headerwerte von public bzw private. übersetzt. Wie im Abschnitt NoStore und Location.None erwähnt, legt die Einstellung Location auf None sowohl als auch Cache-ControlPragma Header auf fest no-cache.

Location.Any (Cache-Control auf publicfestgelegt) gibt an, dass der Client oder ein beliebiger Zwischenproxy den Wert zwischenspeichern kann, einschließlich Middleware für das Zwischenspeichern von Antworten.

Location.Client (Cache-Control auf privatefestgelegt) gibt an, dass nur der Client den Wert zwischenspeichern kann. Kein Zwischencache sollte den Wert zwischenspeichern, einschließlich Middleware für das Zwischenspeichern von Antworten.

Cachesteuerelementheader stellen lediglich Anleitungen für Clients und Zwischenproxys bereit, wann und wie Antworten zwischengespeichert werden. Es gibt keine Garantie, dass Clients und Proxys die HTTP 1.1 Caching-Spezifikation einhalten. Die Middleware für das Zwischenspeichern von Antworten folgt immer den Incachingregeln, die in der Spezifikation festgelegt sind.

Das folgende Beispiel zeigt das Cache3-Seitenmodell aus der Beispiel-App und die Header, die durch Festlegen Duration und Belassen des Standardwerts Location erzeugt werden:

[ResponseCache(Duration = 10, Location = ResponseCacheLocation.Any, NoStore = false)]
public class Cache3Model : PageModel
{

Die Beispiel-App gibt die Seite Cache3 mit dem folgenden Header zurück:

Cache-Control: public,max-age=10

Cacheprofile

Anstatt die Einstellungen des Antwortcaches für viele Controlleraktionsattribute zu duplizieren, können Cacheprofile beim Einrichten von MVC/Razor Pages in Startup.ConfigureServicesals Optionen konfiguriert werden. Werte in einem Cacheprofil, auf das verwiesen wird, werden von ResponseCacheAttribute als Standardwerte verwendet und von allen Eigenschaften überschrieben, die für das Attribut angegeben sind.

Richten Sie ein Cacheprofil ein. Das folgende Beispiel zeigt ein 30-Sekunden-Cacheprofil im der Beispiel-App Startup.ConfigureServices:

public void ConfigureServices(IServiceCollection services)
{
    services.AddRazorPages();
    services.AddMvc(options =>
    {
        options.CacheProfiles.Add("Default30",
            new CacheProfile()
            {
                Duration = 30
            });
    });
}

Das Cache4-Seitenmodell der Beispiel-App verweist auf das Default30 Cacheprofil:

[ResponseCache(CacheProfileName = "Default30")]
public class Cache4Model : PageModel
{

Kann ResponseCacheAttribute auf Folgendes angewendet werden:

  • Razor Pages: Attribute können nicht auf Handlermethoden angewendet werden.
  • MVC-Controller.
  • MVC-Aktionsmethoden: Attribute auf Methodenebene überschreiben die in Attributen auf Klassenebene angegebenen Einstellungen.

Der resultierende Header, der vom Cacheprofil auf die Default30 Cache4-Seitenantwort angewendet wird:

Cache-Control: public,max-age=30

Zusätzliche Ressourcen