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

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();

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.

Der obige Code gibt in der Regel keinen zwischengespeicherten Wert an einen Browser zurück. Verwenden Sie Fiddler 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.

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.

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 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.

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

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.

Anzeigen oder Herunterladen von Beispielcode (Vorgehensweise zum Herunterladen)

Konfiguration

Die Middleware zum Zwischenspeichern von Antworten ist für ASP.NET Core-Apps implizit über das gemeinsam genutzte Framework verfügbar.

Fügen Sie die Middleware zum Zwischenspeichern von Antworten in Startup.ConfigureServices zur Dienstsammlung hinzu:

public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCaching();
    services.AddRazorPages();
}

Konfigurieren Sie die App mithilfe der Erweiterungsmethode UseResponseCaching für die Verwendung der Middleware. Dadurch wird die Middleware zur Pipeline für die Verarbeitung von Anforderungen in Startup.Configure hinzugefügt:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    else
    {
        app.UseExceptionHandler("/Error");
    }

    app.UseStaticFiles();
    app.UseRouting();
    // UseCors must be called before UseResponseCaching
    // app.UseCors("myAllowSpecificOrigins");

    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.UseEndpoints(endpoints =>
    {
        endpoints.MapRazorPages();
    });
}

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.

// using Microsoft.AspNetCore.Http;

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();
});

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.

Tastatur

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

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.

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

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.

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

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, kann ein Browser Anforderungsheader festlegen, die sich auf unerwünschte Weise auf die Zwischenspeicherung auswirken. Ein Browser kann beispielsweise den Cache-Control-Header auf no-cache oder max-age=0 festlegen, wenn eine Seite aktualisiert wird. Die folgenden Tools können Anforderungsheader explizit festlegen und werden daher bevorzugt zum Testen der Zwischenspeicherung eingesetzt:

• Fiddler

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.
• In Startup.Configure muss die Middleware zum Zwischenspeichern von Antworten 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.

Zusätzliche Ressourcen

• 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