Middleware für das Zwischenspeichern von Antworten in ASP.NET Core

Von John Luo und Rick Anderson

In diesem Artikel wird erläutert, wie die Middleware zum Zwischenspeichern von Antworten in einer ASP.NET Core-App konfiguriert wird. Die Middleware bestimmt, wann Antworten zwischenspeicherbar sind, speichert Antworten und stellt Antworten aus dem Cache bereit. Eine Einführung in die HTTP-Zwischenspeicherung und das [ResponseCache]-Attribut finden Sie unter Zwischenspeichern von Antworten.

Für die Middleware zum Zwischenspeichern von Antworten gilt Folgendes:

• Ermöglicht das Zwischenspeichern von Serverantworten basierend auf HTTP-Cacheheadern. Implementiert die standardmäßige HTTP-Zwischenspeicherungssemantik. Führt die Zwischenspeicherung basierend auf HTTP-Cacheheadern durch – genauso wie Proxys.
• Ist in der Regel nicht vorteilhaft für Benutzeroberflächen-Apps wie Razor Pages, da Browser im Allgemeinen Anforderungsheader festlegen, die das Zwischenspeichern verhindern. Benutzeroberflächen-Apps profitieren von der Ausgabezwischenspeicherung, die in ASP.NET Core 7.0 und höher verfügbar ist. Bei der Ausgabezwischenspeicherung entscheidet die Konfiguration unabhängig von HTTP-Headern, was zwischengespeichert werden soll.
• Dies kann bei öffentlichen GET- oder HEAD API-Anforderungen von Clients von Vorteil sein, wenn die Bedingungen für die Zwischenspeicherung erfüllt sind.

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

Konfiguration

Fügen Sie in Program.cs die Dienste für die Middleware zum Zwischenspeichern von Antworten (AddResponseCaching) zur Dienstsammlung hinzu, und konfigurieren Sie die App mit der Erweiterungsmethode UseResponseCaching für die Verwendung der Middleware. UseResponseCaching fügt die Middleware zur Pipeline zur Verarbeitung der Anforderungen hinzu:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCaching();

var app = builder.Build();

app.UseHttpsRedirection();

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

app.UseResponseCaching();

Warnung

UseCors muss vor UseResponseCaching aufgerufen werden, wenn CORS-Middleware verwendet wird.

Die Beispiel-App fügt Header hinzu, um die Zwischenspeicherung bei nachfolgenden Anforderungen zu steuern:

• Cache-Control: Speichert Antworten, die zwischenspeicherbar sind, bis zu 10 Sekunden lang zwischen.
• Vary: Konfiguriert die Middleware so, dass nur dann eine zwischengespeicherte Antwort geliefert wird, wenn der Accept-Encoding-Header nachfolgender Anforderungen mit dem Header der ursprünglichen Anforderung übereinstimmt.

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCaching();

var app = builder.Build();

app.UseHttpsRedirection();

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

app.UseResponseCaching();

app.Use(async (context, next) =>
{
    context.Response.GetTypedHeaders().CacheControl =
        new Microsoft.Net.Http.Headers.CacheControlHeaderValue()
        {
            Public = true,
            MaxAge = TimeSpan.FromSeconds(10)
        };
    context.Response.Headers[Microsoft.Net.Http.Headers.HeaderNames.Vary] =
        new string[] { "Accept-Encoding" };

    await next();
});

app.MapGet("/", () => DateTime.Now.Millisecond);

app.Run();

Die vorherigen Header werden nicht in die Antwort geschrieben, und sie werden überschrieben, wenn für einen Controller, eine Aktion oder eine Razor Page Folgendes gilt:

• Enthält ein [ResponseCache]-Attribut. Dies gilt auch dann, wenn keine Eigenschaft festgelegt ist. Wenn beispielsweise die Eigenschaft VaryByHeader weggelassen wird, wird der entsprechende Header aus der Antwort entfernt.

Die Middleware zum Zwischenspeichern von Antworten speichert nur Serverantworten zwischen, die zu einem Code mit Status 200 (OK) führen. Alle anderen Antworten – einschließlich Fehlerseiten – werden von der Middleware ignoriert.

Warnung

Antworten, die Inhalte für authentifizierte Clients enthalten, müssen als „nicht zwischenspeicherbar“ markiert werden, damit die Middleware diese Antworten nicht speichert und bereitstellt. Informationen dazu, wie die Middleware ermittelt, ob eine Antwort zwischenspeicherbar ist, finden Sie unter Bedingungen für die Zwischenspeicherung.

Der obige Code gibt in der Regel keinen zwischengespeicherten Wert an einen Browser zurück. Verwenden Sie Fiddler, Postman oder ein anderes Tool, das Anforderungsheader explizit festlegen kann und daher bevorzugt zum Testen der Zwischenspeicherung eingesetzt wird. Weitere Informationen finden Sie in diesem Artikel im Abschnitt Problembehandlung.

Tastatur

Die folgende Tabelle enthält Optionen für das Zwischenspeichern von Antworten.

Option	Beschreibung
MaximumBodySize	Die größte zwischenspeicherbare Größe für den Antworttext in Bytes. Der Standardwert ist 64 * 1024 * 1024 (64 MB).
SizeLimit	Die Größenbegrenzung für die Middleware zum Zwischenspeichern von Antworten in Bytes. Der Standardwert ist 100 * 1024 * 1024 (100 MB).
UseCaseSensitivePaths	Bestimmt, ob Antworten in Pfaden zwischengespeichert werden, bei denen die Groß-/Kleinschreibung beachtet wird. Der Standardwert ist false.

Das folgende Beispiel konfiguriert die Middleware für Folgendes:

• Zwischenspeichern von Antworten mit einer Textgröße kleiner/gleich 1.024 Bytes.
• Speichern der Antworten in Pfaden, bei denen die Groß-/Kleinschreibung beachtet wird. Beispielsweise werden /page1 und /Page1 separat gespeichert.

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCaching(options =>
{
    options.MaximumBodySize = 1024;
    options.UseCaseSensitivePaths = true;
});

var app = builder.Build();

app.UseHttpsRedirection();

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

app.UseResponseCaching();

app.Use(async (context, next) =>
{
    context.Response.GetTypedHeaders().CacheControl =
        new Microsoft.Net.Http.Headers.CacheControlHeaderValue()
        {
            Public = true,
            MaxAge = TimeSpan.FromSeconds(10)
        };
    context.Response.Headers[Microsoft.Net.Http.Headers.HeaderNames.Vary] =
        new string[] { "Accept-Encoding" };

    await next(context);
});

app.MapGet("/", () => DateTime.Now.Millisecond);

app.Run();

VaryByQueryKeys

Bei Verwendung von MVC- oder Web-API-Controllern oder Razor Pages-Seitenmodellen gibt das [ResponseCache]-Attribut die Parameter an, die zum Festlegen der geeigneten Header für die Zwischenspeicherung von Antworten erforderlich sind. Der einzige Parameter des [ResponseCache]-Attributs, der unbedingt die Middleware erfordert, ist VaryByQueryKeys – was keinem tatsächlichen Header entspricht. Weitere Informationen finden Sie unter Zwischenspeichern von Antworten in ASP.NET Core.

Wenn das [ResponseCache]-Attribut nicht verwendet wird, kann die Zwischenspeicherung von Antworten mit VaryByQueryKeys variiert werden. Verwenden Sie ResponseCachingFeature direkt aus HttpContext.Features:

var responseCachingFeature = context.HttpContext.Features.Get<IResponseCachingFeature>();

if (responseCachingFeature != null)
{
    responseCachingFeature.VaryByQueryKeys = new[] { "MyKey" };
}

Die Verwendung eines einzelnen Werts gleich * in VaryByQueryKeys variiert den Cache anhand sämtlicher Abfrageparameter der Anforderung.

Von der Middleware zum Zwischenspeichern von Antworten verwendete HTTP-Header

Die folgende Tabelle enthält Informationen zu HTTP-Headern, die sich auf das Zwischenspeichern von Antworten auswirken.

Header	Details
Authorization	Die Antwort wird nicht zwischengespeichert, wenn der Header vorhanden ist.
Cache-Control	Die Middleware speichert nur Antworten zwischen, die mit der Cacheanweisung public markiert sind. Steuern Sie die Zwischenspeicherung mit den folgenden Parametern: max-age max-stale† min-fresh must-revalidate no-cache no-store only-if-cached private public s-maxage proxy-revalidate‡ †Wenn für max-stale kein Limit angegeben ist, führt die Middleware keine Aktion aus. ‡proxy-revalidate hat dieselben Auswirkungen wie must-revalidate. Weitere Informationen finden Sie unter RFC 9111: Request Directives.
Pragma	Ein Pragma: no-cache-Header in der Anforderung hat dieselbe Wirkung wie Cache-Control: no-cache. Dieser Header wird von den entsprechenden Anweisungen im Cache-Control-Header überschrieben, sofern vorhanden. Wird aus Gründen der Abwärtskompatibilität mit HTTP/1.0 berücksichtigt.
Set-Cookie	Die Antwort wird nicht zwischengespeichert, wenn der Header vorhanden ist. Jegliche Middleware in der Pipeline zur Verarbeitung der Anforderung, die mindestens ein cookie festlegt, verhindert, dass die Middleware zum Zwischenspeichern von Antworten die Antwort zwischenspeichert (beispielsweise der cookie-basierte TempData-Anbieter).
Vary	Der Vary-Header wird zum Variieren der zwischengespeicherten Antwort durch einen anderen Header verwendet. Sie können beispielsweise Antworten anhand der Codierung zwischenspeichern, indem Sie den Vary: Accept-Encoding-Header einschließen, der Antworten auf Anforderungen mit den Headern Accept-Encoding: gzip und Accept-Encoding: text/plain separat zwischenspeichert. Eine Antwort mit dem Headerwert * wird nie zwischengespeichert.
Expires	Eine Antwort, die von diesem Header als veraltet betrachtet wird, wird weder gespeichert noch abgerufen, es sei denn, dies wird von anderen Cache-Control-Headern überschrieben.
If-None-Match	Die vollständige Antwort wird aus dem Cache geliefert, wenn der Wert nicht * lautet und das ETag der Antwort mit keinem der bereitgestellten Werte übereinstimmt. Andernfalls wird eine Antwort vom Typ 304 (Nicht geändert) zurückgegeben.
If-Modified-Since	Wenn der If-None-Match-Header nicht vorhanden ist, wird eine vollständige Antwort aus dem Cache geliefert, wenn das Datum der zwischengespeicherten Antwort neuer ist als der bereitgestellte Wert. Andernfalls wird eine Antwort vom Typ 304 (Nicht geändert) zurückgegeben.
Date	Bei der Rückgabe aus dem Cache wird der Date-Header von der Middleware festgelegt, wenn er in der ursprünglichen Antwort nicht bereitgestellt wurde.
Content-Length	Bei der Rückgabe aus dem Cache wird der Content-Length-Header von der Middleware festgelegt, wenn er in der ursprünglichen Antwort nicht bereitgestellt wurde.
Age	Der in der ursprünglichen Anforderung gesendete Age-Header wird ignoriert. Die Middleware berechnet beim Liefern einer zwischengespeicherten Antwort einen neuen Wert.

Zwischenspeicherung berücksichtigt Cache-Control-Anweisungen der Anforderung

Die Middleware berücksichtigt die Regeln von RFC 9111: HTTP Caching (Section 5.2. Cache-Control). Die Regeln erfordern, dass ein Cache einen vom Client gesendeten gültigen Cache-Control-Header berücksichtigt. In dieser Spezifikation kann ein Client Anforderungen mit dem Headerwert no-cache senden und den Server zwingen, für jede Anforderung eine neue Antwort zu generieren. Derzeit können Entwickler*innen dieses Verhalten der Zwischenspeicherung bei Verwendung der Middleware nicht steuern, da die Middleware die offizielle Spezifikation für die Zwischenspeicherung einhält.

Wenn Sie das Verhalten der Zwischenspeicherung besser steuern möchten, sehen Sie sich andere ASP.NET Core-Features für die Zwischenspeicherung an. Weitere Informationen finden Sie in den folgenden Artikeln:

• Zwischenspeichern im Arbeitsspeicher in ASP.NET Core
• Verteiltes Zwischenspeichern in ASP.NET Core
• Cache-Taghilfsprogramm im ASP.NET Core MVC
• Taghilfsprogramm für verteilten Cache in ASP.NET Core

Problembehandlung

Die Middleware zum Zwischenspeichern von Antworten verwendet die Schnittstelle IMemoryCache, die nur über begrenzte Kapazität verfügt. Wenn diese Kapazität überschritten wird, wird der Arbeitsspeichercache komprimiert.

Wenn das Verhalten der Zwischenspeicherung nicht den Erwartungen entspricht, vergewissern Sie sich, dass Antworten zwischenspeicherbar sind und aus dem Cache geliefert werden können. Untersuchen Sie die eingehenden Header der Anforderung und die ausgehenden Header der Antwort. Aktivieren Sie die Protokollierung zur Unterstützung des Debuggings.

Wenn das Verhalten der Zwischenspeicherung getestet wird und Probleme behoben werden, legt ein Browser in der Regel Anforderungsheader fest, die eine Zwischenspeicherung verhindern. Ein Browser kann beispielsweise den Cache-Control-Header auf no-cache oder max-age=0 festlegen, wenn eine Seite aktualisiert wird. Fiddler, Postman und andere Tools können Anforderungsheader explizit festlegen und werden daher bevorzugt zum Testen der Zwischenspeicherung eingesetzt.

Bedingungen für die Zwischenspeicherung

• Die Anforderung muss zu einer Serverantwort mit einem Statuscode vom Typ 200 (OK) führen.
• Die Anforderungsmethode muss GET oder HEAD sein.
• Die Middleware zum Zwischenspeichern von Antworten muss vor jeglicher Middleware platziert werden, die eine Zwischenspeicherung erfordert. Weitere Informationen finden Sie unter ASP.NET Core-Middleware.
• Der Authorization-Header darf nicht vorhanden sein.
• Parameter des Cache-Control-Headers müssen gültig sein, und die Antwort muss als public markiert sein. Sie darf nicht als private markiert sein.
• Der Pragma: no-cache-Header darf nicht vorhanden sein, denn der Cache-Control-Header vorhanden ist, da der Cache-Control-Header, wenn vorhanden, den Pragma-Header überschreibt.
• Der Set-Cookie-Header darf nicht vorhanden sein.
• Parameter des Vary-Headers müssen gültig und ungleich * sein.
• Der Wert des Content-Length-Headers (sofern festgelegt) muss der Größe des Antworttexts entsprechen.
• Das IHttpSendFileFeature wird nicht verwendet.
• Die Antwort darf nicht veraltet sein, wie vom Expires-Header und den Cacheanweisungen max-age und s-maxage angegeben.
• Die Antwortpufferung muss erfolgreich sein. Die Antwort muss kleiner sein als der konfigurierte Wert oder der Standardwert für SizeLimit. Der Text der Antwort muss kleiner sein als der konfigurierte Wert oder der Standardwert für MaximumBodySize.
• Die Antwort muss gemäß RFC 9111: HTTP Caching zwischenspeicherbar sein. Beispielsweise darf die no-store-Anweisung in den Anforderungs- oder Antwortheaderfeldern nicht vorhanden sein. Details dazu finden Sie unter RFC 9111: HTTP Caching (Section 3: Storing Responses in Caches.

Hinweis

Das System zum Schutz vor Fälschung, mit dem zum Verhindern von CSRF-Angriffen (Cross-Site Request Forgery, websiteübergreifende Anforderungsfälschung) sichere Token generiert werden, legt die Header Cache-Control und Pragma auf no-cache fest, sodass Antworten nicht zwischengespeichert werden. Informationen zum Deaktivieren von Token zum Schutz vor Fälschung für HTML-Formularelemente finden Sie unter Verhindern von Angriffen durch XSRF/CSRF (Cross-Site Request Forgery, websiteübergreifende Anforderungsfälschung).

Zusätzliche Ressourcen

• Anzeigen oder Herunterladen von Beispielcode (Vorgehensweise zum Herunterladen)
• GitHub-Quelle für IResponseCachingPolicyProvider
• GitHub-Quelle für IResponseCachingPolicyProvider
• Anwendungsstart in ASP.NET Core
• ASP.NET Core-Middleware
• Zwischenspeichern im Arbeitsspeicher in ASP.NET Core
• Verteiltes Zwischenspeichern in ASP.NET Core
• Erkennen von Änderungen mit Änderungstoken in ASP.NET Core
• Zwischenspeichern von Antworten in ASP.NET Core
• Cache-Taghilfsprogramm im ASP.NET Core MVC
• Taghilfsprogramm für verteilten Cache in ASP.NET Core