ASP.NET Core での応答キャッシュミドルウェアResponse Caching Middleware in ASP.NET Core

作成者: John LuoBy John Luo

この記事では、ASP.NET Core アプリで応答キャッシュミドルウェアを構成する方法について説明します。This article explains how to configure Response Caching Middleware in an ASP.NET Core app. ミドルウェアは、応答をキャッシュ可能にするタイミングを決定し、応答を格納して、キャッシュからの応答を提供します。The middleware determines when responses are cacheable, stores responses, and serves responses from cache. HTTP キャッシュと属性の概要につい [ResponseCache] ては、「 応答キャッシュ」を参照してください。For an introduction to HTTP caching and the [ResponseCache] attribute, see Response Caching.

サンプル コードを表示またはダウンロードします (ダウンロード方法)。View or download sample code (how to download)

構成Configuration

応答キャッシュミドルウェアは、共有フレームワークを介して ASP.NET Core アプリで暗黙的に使用できます。Response Caching Middleware is implicitly available for ASP.NET Core apps via the shared framework.

Startup.ConfigureServices 、応答キャッシュミドルウェアをサービスコレクションに追加します。In Startup.ConfigureServices, add the Response Caching Middleware to the service collection:

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

拡張メソッドと共にミドルウェアを使用するようにアプリを構成し UseResponseCaching ます。これにより、の要求処理パイプラインにミドルウェアが追加され Startup.Configure ます。Configure the app to use the middleware with the UseResponseCaching extension method, which adds the middleware to the request processing pipeline in Startup.Configure:

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

警告

UseCorsUseResponseCaching CORS ミドルウェアを使用する場合は、前にを呼び出す必要があります。UseCors must be called before UseResponseCaching when using CORS middleware.

サンプルアプリでは、後続の要求でキャッシュを制御するためのヘッダーを追加します。The sample app adds headers to control caching on subsequent requests:

  • Cache-control: キャッシュ可能な応答を最大10秒間キャッシュします。Cache-Control: Caches cacheable responses for up to 10 seconds.
  • Vary: 後続の要求の エンコーディング ヘッダーが元の要求と一致する場合にのみ、キャッシュされた応答を提供するようにミドルウェアを構成します。Vary: Configures the middleware to serve a cached response only if the Accept-Encoding header of subsequent requests matches that of the original request.
// 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();
});

前のヘッダーは応答に書き込まれず、コントローラー、アクション、またはページでオーバーライドされ Razor ます。The preceding headers are not written to the response and are overridden when a controller, action, or Razor Page:

  • には [ResponseCache] 属性があります。Has a [ResponseCache] attribute. これは、プロパティが設定されていない場合でも適用されます。This applies even if a property isn't set. たとえば、 VaryByHeader プロパティを省略すると、対応するヘッダーが応答から削除されます。For example, omitting the VaryByHeader property will cause the corresponding header to be removed from the response.

応答キャッシュミドルウェアは、200 (OK) 状態コードを生成するサーバー応答のみをキャッシュします。Response Caching Middleware only caches server responses that result in a 200 (OK) status code. エラーページを含むその他の応答は、ミドルウェアによって無視されます。Any other responses, including error pages, are ignored by the middleware.

警告

認証されたクライアントのコンテンツを含む応答は、ミドルウェアがそれらの応答を格納してサービスを提供しないように、キャッシュ不可能としてマークする必要があります。Responses containing content for authenticated clients must be marked as not cacheable to prevent the middleware from storing and serving those responses. 応答がキャッシュ可能かどうかをミドルウェアが決定する方法の詳細については、「 キャッシュの条件 」を参照してください。See Conditions for caching for details on how the middleware determines if a response is cacheable.

OptionsOptions

応答キャッシュのオプションを次の表に示します。Response caching options are shown in the following table.

オプションOption 説明Description
MaximumBodySize 応答本文の最大キャッシュ可能サイズ (バイト単位)。The largest cacheable size for the response body in bytes. 既定値は 64 * 1024 * 1024 (64 MB) です。The default value is 64 * 1024 * 1024 (64 MB).
SizeLimit 応答キャッシュミドルウェアのサイズ制限 (バイト単位)。The size limit for the response cache middleware in bytes. 既定値は 100 * 1024 * 1024 (100 MB) です。The default value is 100 * 1024 * 1024 (100 MB).
UseCaseSensitivePaths 大文字と小文字が区別されるパスに応答をキャッシュするかどうかを決定します。Determines if responses are cached on case-sensitive paths. 既定値は false です。The default value is false.

次の例では、ミドルウェアをに構成します。The following example configures the middleware to:

  • 本文のサイズが1024バイト以下の応答をキャッシュします。Cache responses with a body size smaller than or equal to 1,024 bytes.
  • 大文字と小文字を区別するパスで応答を格納します。Store the responses by case-sensitive paths. たとえば、 /page1/Page1 は別々に格納されます。For example, /page1 and /Page1 are stored separately.
services.AddResponseCaching(options =>
{
    options.MaximumBodySize = 1024;
    options.UseCaseSensitivePaths = true;
});

VaryByQueryKeysVaryByQueryKeys

MVC/web API コントローラーまたは Razor ページのページモデルを使用する場合、属性は、 [ResponseCache] 応答のキャッシュに適切なヘッダーを設定するために必要なパラメーターを指定します。When using MVC / web API controllers or Razor Pages page models, the [ResponseCache] attribute specifies the parameters necessary for setting the appropriate headers for response caching. ミドルウェアを厳密に必要とする属性の唯一のパラメーター [ResponseCache]VaryByQueryKeys 、実際の HTTP ヘッダーに対応していません。The only parameter of the [ResponseCache] attribute that strictly requires the middleware is VaryByQueryKeys, which doesn't correspond to an actual HTTP header. 詳細については、「ASP.NET Core での応答のキャッシュ」を参照してください。For more information, see ASP.NET Core での応答のキャッシュ.

属性を使用しない場合は、を使用して [ResponseCache] 応答のキャッシュを変化させることができ VaryByQueryKeys ます。When not using the [ResponseCache] attribute, response caching can be varied with VaryByQueryKeys. ResponseCachingFeature HttpContext から直接使用します。Use the ResponseCachingFeature directly from the HttpContext.Features:

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

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

で1つの値を使用すると * VaryByQueryKeys 、すべての要求クエリパラメーターによってキャッシュが異なります。Using a single value equal to * in VaryByQueryKeys varies the cache by all request query parameters.

応答キャッシュミドルウェアによって使用される HTTP ヘッダーHTTP headers used by Response Caching Middleware

次の表は、応答のキャッシュに影響を与える HTTP ヘッダーに関する情報を示しています。The following table provides information on HTTP headers that affect response caching.

ヘッダーHeader 詳細情報Details
Authorization ヘッダーが存在する場合、応答はキャッシュされません。The response isn't cached if the header exists.
Cache-Control ミドルウェアは、cache ディレクティブでマークされたキャッシュ応答のみを考慮し public ます。The middleware only considers caching responses marked with the public cache directive. 次のパラメーターを使用してキャッシュを制御します。Control caching with the following parameters:
  • 最長有効期間max-age
  • 最大-古い†max-stale†
  • 最小-新規min-fresh
  • must-revalidatemust-revalidate
  • no-cacheno-cache
  • ストアなしno-store
  • -if-キャッシュ済みonly-if-cached
  • プライベートprivate
  • publicpublic
  • s-maxages-maxage
  • プロキシ再検証‡proxy-revalidate‡
†に制限が指定されていない場合 max-stale 、ミドルウェアは何も実行しません。†If no limit is specified to max-stale, the middleware takes no action.
proxy-revalidate はと同じ効果があり must-revalidate ます。proxy-revalidate has the same effect as must-revalidate.

詳細については、「 RFC 7231: Request Cache-Control ディレクティブ」を参照してください。For more information, see RFC 7231: Request Cache-Control Directives.
Pragma 要求のヘッダーでは、 Pragma: no-cache と同じ効果が得られ Cache-Control: no-cache ます。A Pragma: no-cache header in the request produces the same effect as Cache-Control: no-cache. このヘッダーは、ヘッダー内の関連するディレクティブによってオーバーライドされ Cache-Control ます (存在する場合)。This header is overridden by the relevant directives in the Cache-Control header, if present. HTTP/1.0 との下位互換性のために考慮されます。Considered for backward compatibility with HTTP/1.0.
Set-Cookie ヘッダーが存在する場合、応答はキャッシュされません。The response isn't cached if the header exists. 1つ以上のを設定する要求処理パイプライン内のすべてのミドルウェア cookie は、応答キャッシュミドルウェアが応答をキャッシュしないようにします (たとえば、 cookie ベースの tempdata プロバイダー)。Any middleware in the request processing pipeline that sets one or more cookies prevents the Response Caching Middleware from caching the response (for example, the cookie-based TempData provider).
Vary Varyヘッダーは、キャッシュされた応答を別のヘッダーによって変更するために使用されます。The Vary header is used to vary the cached response by another header. たとえば、ヘッダーを含めることによって、エンコードによって応答をキャッシュし Vary: Accept-Encoding ます。ヘッダーとは別に要求の応答をキャッシュし Accept-Encoding: gzip Accept-Encoding: text/plain ます。For example, cache responses by encoding by including the Vary: Accept-Encoding header, which caches responses for requests with headers Accept-Encoding: gzip and Accept-Encoding: text/plain separately. ヘッダー値がの応答 * は格納されません。A response with a header value of * is never stored.
Expires このヘッダーによって古いと見なされる応答は、他のヘッダーでオーバーライドされない限り、格納または取得されません Cache-ControlA response deemed stale by this header isn't stored or retrieved unless overridden by other Cache-Control headers.
If-None-Match 値がではなく、 * 応答のが指定された値と一致しない場合は、完全な応答がキャッシュから提供され ETag ます。The full response is served from cache if the value isn't * and the ETag of the response doesn't match any of the values provided. それ以外の場合は、304 (変更なし) の応答が処理されます。Otherwise, a 304 (Not Modified) response is served.
If-Modified-Since ヘッダーが存在しない場合、キャッシュされた If-None-Match 応答の日付が指定した値より新しい場合は、完全な応答がキャッシュから提供されます。If the If-None-Match header isn't present, a full response is served from cache if the cached response date is newer than the value provided. それ以外の場合は、 304-変更されていない 応答が提供されます。Otherwise, a 304 - Not Modified response is served.
Date キャッシュからサービスを提供している場合、 Date ヘッダーはミドルウェアによって設定されます (元の応答で指定されていない場合)。When serving from cache, the Date header is set by the middleware if it wasn't provided on the original response.
Content-Length キャッシュからサービスを提供している場合、 Content-Length ヘッダーはミドルウェアによって設定されます (元の応答で指定されていない場合)。When serving from cache, the Content-Length header is set by the middleware if it wasn't provided on the original response.
Age Age元の応答で送信されたヘッダーは無視されます。The Age header sent in the original response is ignored. ミドルウェアは、キャッシュされた応答を提供するときに新しい値を計算します。The middleware computes a new value when serving a cached response.

キャッシュは要求 Cache-Control ディレクティブを尊重しますCaching respects request Cache-Control directives

ミドルウェアは、 HTTP 1.1 キャッシュ仕様の規則を尊重します。The middleware respects the rules of the HTTP 1.1 Caching specification. 規則では、 Cache-Control クライアントによって送信された有効なヘッダーを受け入れるためにキャッシュが必要です。The rules require a cache to honor a valid Cache-Control header sent by the client. この仕様では、クライアントはヘッダー値を使用して要求を行い、 no-cache すべての要求に対してサーバーに新しい応答を強制的に生成させることができます。Under the specification, a client can make requests with a no-cache header value and force the server to generate a new response for every request. 現時点では、ミドルウェアが公式のキャッシュ仕様に準拠しているため、ミドルウェアを使用する場合、このキャッシュ動作を開発者が制御することはありません。Currently, there's no developer control over this caching behavior when using the middleware because the middleware adheres to the official caching specification.

キャッシュの動作を詳細に制御するには、ASP.NET Core の他のキャッシュ機能を調べます。For more control over caching behavior, explore other caching features of ASP.NET Core. 次のトピックを参照してください。See the following topics:

トラブルシューティングTroubleshooting

キャッシュの動作が想定どおりでない場合は、応答がキャッシュ可能であり、キャッシュから提供できることを確認します。If caching behavior isn't as expected, confirm that responses are cacheable and capable of being served from the cache. 要求の受信ヘッダーと応答の送信ヘッダーを確認します。Examine the request's incoming headers and the response's outgoing headers. デバッグに役立つように ログ記録 を有効にします。Enable logging to help with debugging.

キャッシュ動作のテストとトラブルシューティングを行う場合、ブラウザーでは、望ましくない方法でキャッシュに影響を与える要求ヘッダーを設定できます。When testing and troubleshooting caching behavior, a browser may set request headers that affect caching in undesirable ways. たとえば、ページを更新するときに、ブラウザーで Cache-Control ヘッダーをまたはに設定でき no-cache max-age=0 ます。For example, a browser may set the Cache-Control header to no-cache or max-age=0 when refreshing a page. 次のツールでは、要求ヘッダーを明示的に設定でき、キャッシュのテストに適しています。The following tools can explicitly set request headers and are preferred for testing caching:

キャッシュの条件Conditions for caching

  • 要求は、200 (OK) 状態コードでサーバー応答を生成する必要があります。The request must result in a server response with a 200 (OK) status code.
  • 要求メソッドは GET または HEAD である必要があります。The request method must be GET or HEAD.
  • では Startup.Configure 、応答キャッシュミドルウェアは、キャッシュを必要とするミドルウェアの前に配置する必要があります。In Startup.Configure, Response Caching Middleware must be placed before middleware that require caching. 詳細については、「ASP.NET Core のミドルウェア」を参照してください。For more information, see ASP.NET Core のミドルウェア.
  • ヘッダーを指定することはでき Authorization ません。The Authorization header must not be present.
  • Cache-Control ヘッダーパラメーターは有効である必要があり、応答はとマークされている必要があり public private ます。Cache-Control header parameters must be valid, and the response must be marked public and not marked private.
  • ヘッダーが存在する場合、ヘッダーはヘッダーをオーバーライドするので、ヘッダーが存在しない場合はヘッダーが Pragma: no-cache 存在しない必要があり Cache-Control Cache-Control Pragma ます。The Pragma: no-cache header must not be present if the Cache-Control header isn't present, as the Cache-Control header overrides the Pragma header when present.
  • ヘッダーを指定することはでき Set-Cookie ません。The Set-Cookie header must not be present.
  • Vary ヘッダーパラメーターはと同じである必要があり * ます。Vary header parameters must be valid and not equal to *.
  • Content-Lengthヘッダー値 (設定されている場合) は、応答本文のサイズと一致する必要があります。The Content-Length header value (if set) must match the size of the response body.
  • IHttpSendFileFeature 使用されません。The IHttpSendFileFeature isn't used.
  • Expiresヘッダー、および、およびの各 max-age キャッシュディレクティブで指定されているとおり、応答を古いものにすることはできません s-maxageThe response must not be stale as specified by the Expires header and the max-age and s-maxage cache directives.
  • 応答バッファリングを成功させる必要があります。Response buffering must be successful. 応答のサイズは、構成済みまたは既定値よりも小さくする必要があり SizeLimit ます。The size of the response must be smaller than the configured or default SizeLimit. 応答の本文のサイズは、構成済みまたは既定値よりも小さくする必要があり MaximumBodySize ます。The body size of the response must be smaller than the configured or default MaximumBodySize.
  • 応答は、 RFC 7234 仕様に従ってキャッシュ可能である必要があります。The response must be cacheable according to the RFC 7234 specifications. たとえば、ディレクティブは、 no-store 要求または応答のヘッダーフィールドに存在することはできません。For example, the no-store directive must not exist in request or response header fields. 詳細については、 「セクション 3: RFC 7234 のキャッシュに応答を格納する」を参照してください。See Section 3: Storing Responses in Caches of RFC 7234 for details.

注意

クロスサイト要求偽造 (CSRF) 攻撃を防ぐために、セキュリティで保護されたトークンを生成するための偽造防止システムは、 Cache-Control Pragma 応答がキャッシュされないようにヘッダーとヘッダーをに設定し no-cache ます。The Antiforgery system for generating secure tokens to prevent Cross-Site Request Forgery (CSRF) attacks sets the Cache-Control and Pragma headers to no-cache so that responses aren't cached. HTML フォーム要素の偽造防止トークンを無効にする方法については、「」を参照してください ASP.NET Core でのクロスサイト要求偽造 (XSRF/CSRF) 攻撃を防ぐFor information on how to disable antiforgery tokens for HTML form elements, see ASP.NET Core でのクロスサイト要求偽造 (XSRF/CSRF) 攻撃を防ぐ.

その他のリソースAdditional resources

この記事では、ASP.NET Core アプリで応答キャッシュミドルウェアを構成する方法について説明します。This article explains how to configure Response Caching Middleware in an ASP.NET Core app. ミドルウェアは、応答をキャッシュ可能にするタイミングを決定し、応答を格納して、キャッシュからの応答を提供します。The middleware determines when responses are cacheable, stores responses, and serves responses from cache. HTTP キャッシュと属性の概要につい [ResponseCache] ては、「 応答キャッシュ」を参照してください。For an introduction to HTTP caching and the [ResponseCache] attribute, see Response Caching.

サンプル コードを表示またはダウンロードします (ダウンロード方法)。View or download sample code (how to download)

構成Configuration

AspNetCore メタパッケージを使用するか、 AspNetCoreパッケージへのパッケージ参照を追加します。Use the Microsoft.AspNetCore.App metapackage or add a package reference to the Microsoft.AspNetCore.ResponseCaching package.

Startup.ConfigureServices 、応答キャッシュミドルウェアをサービスコレクションに追加します。In Startup.ConfigureServices, add the Response Caching Middleware to the service collection:

public void ConfigureServices(IServiceCollection services)
{
    services.AddResponseCaching();
    services.AddMvc()
        .SetCompatibilityVersion(CompatibilityVersion.Version_2_2);
}

拡張メソッドと共にミドルウェアを使用するようにアプリを構成し UseResponseCaching ます。これにより、の要求処理パイプラインにミドルウェアが追加され Startup.Configure ます。Configure the app to use the middleware with the UseResponseCaching extension method, which adds the middleware to the request processing pipeline in Startup.Configure:

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

    app.UseStaticFiles();

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

サンプルアプリでは、後続の要求でキャッシュを制御するためのヘッダーを追加します。The sample app adds headers to control caching on subsequent requests:

  • Cache-control: キャッシュ可能な応答を最大10秒間キャッシュします。Cache-Control: Caches cacheable responses for up to 10 seconds.
  • Vary: 後続の要求の エンコーディング ヘッダーが元の要求と一致する場合にのみ、キャッシュされた応答を提供するようにミドルウェアを構成します。Vary: Configures the middleware to serve a cached response only if the Accept-Encoding header of subsequent requests matches that of the original request.
// 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();
});

前のヘッダーは応答に書き込まれず、コントローラー、アクション、またはページでオーバーライドされ Razor ます。The preceding headers are not written to the response and are overridden when a controller, action, or Razor Page:

  • には [ResponseCache] 属性があります。Has a [ResponseCache] attribute. これは、プロパティが設定されていない場合でも適用されます。This applies even if a property isn't set. たとえば、 VaryByHeader プロパティを省略すると、対応するヘッダーが応答から削除されます。For example, omitting the VaryByHeader property will cause the corresponding header to be removed from the response.

応答キャッシュミドルウェアは、200 (OK) 状態コードを生成するサーバー応答のみをキャッシュします。Response Caching Middleware only caches server responses that result in a 200 (OK) status code. エラーページを含むその他の応答は、ミドルウェアによって無視されます。Any other responses, including error pages, are ignored by the middleware.

警告

認証されたクライアントのコンテンツを含む応答は、ミドルウェアがそれらの応答を格納してサービスを提供しないように、キャッシュ不可能としてマークする必要があります。Responses containing content for authenticated clients must be marked as not cacheable to prevent the middleware from storing and serving those responses. 応答がキャッシュ可能かどうかをミドルウェアが決定する方法の詳細については、「 キャッシュの条件 」を参照してください。See Conditions for caching for details on how the middleware determines if a response is cacheable.

OptionsOptions

応答キャッシュのオプションを次の表に示します。Response caching options are shown in the following table.

オプションOption 説明Description
MaximumBodySize 応答本文の最大キャッシュ可能サイズ (バイト単位)。The largest cacheable size for the response body in bytes. 既定値は 64 * 1024 * 1024 (64 MB) です。The default value is 64 * 1024 * 1024 (64 MB).
SizeLimit 応答キャッシュミドルウェアのサイズ制限 (バイト単位)。The size limit for the response cache middleware in bytes. 既定値は 100 * 1024 * 1024 (100 MB) です。The default value is 100 * 1024 * 1024 (100 MB).
UseCaseSensitivePaths 大文字と小文字が区別されるパスに応答をキャッシュするかどうかを決定します。Determines if responses are cached on case-sensitive paths. 既定値は false です。The default value is false.

次の例では、ミドルウェアをに構成します。The following example configures the middleware to:

  • 本文のサイズが1024バイト以下の応答をキャッシュします。Cache responses with a body size smaller than or equal to 1,024 bytes.
  • 大文字と小文字を区別するパスで応答を格納します。Store the responses by case-sensitive paths. たとえば、 /page1/Page1 は別々に格納されます。For example, /page1 and /Page1 are stored separately.
services.AddResponseCaching(options =>
{
    options.MaximumBodySize = 1024;
    options.UseCaseSensitivePaths = true;
});

VaryByQueryKeysVaryByQueryKeys

MVC/web API コントローラーまたは Razor ページのページモデルを使用する場合、属性は、 [ResponseCache] 応答のキャッシュに適切なヘッダーを設定するために必要なパラメーターを指定します。When using MVC / web API controllers or Razor Pages page models, the [ResponseCache] attribute specifies the parameters necessary for setting the appropriate headers for response caching. ミドルウェアを厳密に必要とする属性の唯一のパラメーター [ResponseCache]VaryByQueryKeys 、実際の HTTP ヘッダーに対応していません。The only parameter of the [ResponseCache] attribute that strictly requires the middleware is VaryByQueryKeys, which doesn't correspond to an actual HTTP header. 詳細については、「ASP.NET Core での応答のキャッシュ」を参照してください。For more information, see ASP.NET Core での応答のキャッシュ.

属性を使用しない場合は、を使用して [ResponseCache] 応答のキャッシュを変化させることができ VaryByQueryKeys ます。When not using the [ResponseCache] attribute, response caching can be varied with VaryByQueryKeys. ResponseCachingFeature HttpContext から直接使用します。Use the ResponseCachingFeature directly from the HttpContext.Features:

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

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

で1つの値を使用すると * VaryByQueryKeys 、すべての要求クエリパラメーターによってキャッシュが異なります。Using a single value equal to * in VaryByQueryKeys varies the cache by all request query parameters.

応答キャッシュミドルウェアによって使用される HTTP ヘッダーHTTP headers used by Response Caching Middleware

次の表は、応答のキャッシュに影響を与える HTTP ヘッダーに関する情報を示しています。The following table provides information on HTTP headers that affect response caching.

ヘッダーHeader 詳細情報Details
Authorization ヘッダーが存在する場合、応答はキャッシュされません。The response isn't cached if the header exists.
Cache-Control ミドルウェアは、cache ディレクティブでマークされたキャッシュ応答のみを考慮し public ます。The middleware only considers caching responses marked with the public cache directive. 次のパラメーターを使用してキャッシュを制御します。Control caching with the following parameters:
  • 最長有効期間max-age
  • 最大-古い†max-stale†
  • 最小-新規min-fresh
  • must-revalidatemust-revalidate
  • no-cacheno-cache
  • ストアなしno-store
  • -if-キャッシュ済みonly-if-cached
  • プライベートprivate
  • publicpublic
  • s-maxages-maxage
  • プロキシ再検証‡proxy-revalidate‡
†に制限が指定されていない場合 max-stale 、ミドルウェアは何も実行しません。†If no limit is specified to max-stale, the middleware takes no action.
proxy-revalidate はと同じ効果があり must-revalidate ます。proxy-revalidate has the same effect as must-revalidate.

詳細については、「 RFC 7231: Request Cache-Control ディレクティブ」を参照してください。For more information, see RFC 7231: Request Cache-Control Directives.
Pragma 要求のヘッダーでは、 Pragma: no-cache と同じ効果が得られ Cache-Control: no-cache ます。A Pragma: no-cache header in the request produces the same effect as Cache-Control: no-cache. このヘッダーは、ヘッダー内の関連するディレクティブによってオーバーライドされ Cache-Control ます (存在する場合)。This header is overridden by the relevant directives in the Cache-Control header, if present. HTTP/1.0 との下位互換性のために考慮されます。Considered for backward compatibility with HTTP/1.0.
Set-Cookie ヘッダーが存在する場合、応答はキャッシュされません。The response isn't cached if the header exists. 1つ以上のを設定する要求処理パイプライン内のすべてのミドルウェア cookie は、応答キャッシュミドルウェアが応答をキャッシュしないようにします (たとえば、 cookie ベースの tempdata プロバイダー)。Any middleware in the request processing pipeline that sets one or more cookies prevents the Response Caching Middleware from caching the response (for example, the cookie-based TempData provider).
Vary Varyヘッダーは、キャッシュされた応答を別のヘッダーによって変更するために使用されます。The Vary header is used to vary the cached response by another header. たとえば、ヘッダーを含めることによって、エンコードによって応答をキャッシュし Vary: Accept-Encoding ます。ヘッダーとは別に要求の応答をキャッシュし Accept-Encoding: gzip Accept-Encoding: text/plain ます。For example, cache responses by encoding by including the Vary: Accept-Encoding header, which caches responses for requests with headers Accept-Encoding: gzip and Accept-Encoding: text/plain separately. ヘッダー値がの応答 * は格納されません。A response with a header value of * is never stored.
Expires このヘッダーによって古いと見なされる応答は、他のヘッダーでオーバーライドされない限り、格納または取得されません Cache-ControlA response deemed stale by this header isn't stored or retrieved unless overridden by other Cache-Control headers.
If-None-Match 値がではなく、 * 応答のが指定された値と一致しない場合は、完全な応答がキャッシュから提供され ETag ます。The full response is served from cache if the value isn't * and the ETag of the response doesn't match any of the values provided. それ以外の場合は、304 (変更なし) の応答が処理されます。Otherwise, a 304 (Not Modified) response is served.
If-Modified-Since ヘッダーが存在しない場合、キャッシュされた If-None-Match 応答の日付が指定した値より新しい場合は、完全な応答がキャッシュから提供されます。If the If-None-Match header isn't present, a full response is served from cache if the cached response date is newer than the value provided. それ以外の場合は、 304-変更されていない 応答が提供されます。Otherwise, a 304 - Not Modified response is served.
Date キャッシュからサービスを提供している場合、 Date ヘッダーはミドルウェアによって設定されます (元の応答で指定されていない場合)。When serving from cache, the Date header is set by the middleware if it wasn't provided on the original response.
Content-Length キャッシュからサービスを提供している場合、 Content-Length ヘッダーはミドルウェアによって設定されます (元の応答で指定されていない場合)。When serving from cache, the Content-Length header is set by the middleware if it wasn't provided on the original response.
Age Age元の応答で送信されたヘッダーは無視されます。The Age header sent in the original response is ignored. ミドルウェアは、キャッシュされた応答を提供するときに新しい値を計算します。The middleware computes a new value when serving a cached response.

キャッシュは要求 Cache-Control ディレクティブを尊重しますCaching respects request Cache-Control directives

ミドルウェアは、 HTTP 1.1 キャッシュ仕様の規則を尊重します。The middleware respects the rules of the HTTP 1.1 Caching specification. 規則では、 Cache-Control クライアントによって送信された有効なヘッダーを受け入れるためにキャッシュが必要です。The rules require a cache to honor a valid Cache-Control header sent by the client. この仕様では、クライアントはヘッダー値を使用して要求を行い、 no-cache すべての要求に対してサーバーに新しい応答を強制的に生成させることができます。Under the specification, a client can make requests with a no-cache header value and force the server to generate a new response for every request. 現時点では、ミドルウェアが公式のキャッシュ仕様に準拠しているため、ミドルウェアを使用する場合、このキャッシュ動作を開発者が制御することはありません。Currently, there's no developer control over this caching behavior when using the middleware because the middleware adheres to the official caching specification.

キャッシュの動作を詳細に制御するには、ASP.NET Core の他のキャッシュ機能を調べます。For more control over caching behavior, explore other caching features of ASP.NET Core. 次のトピックを参照してください。See the following topics:

トラブルシューティングTroubleshooting

キャッシュの動作が想定どおりでない場合は、応答がキャッシュ可能であり、キャッシュから提供できることを確認します。If caching behavior isn't as expected, confirm that responses are cacheable and capable of being served from the cache. 要求の受信ヘッダーと応答の送信ヘッダーを確認します。Examine the request's incoming headers and the response's outgoing headers. デバッグに役立つように ログ記録 を有効にします。Enable logging to help with debugging.

キャッシュ動作のテストとトラブルシューティングを行う場合、ブラウザーでは、望ましくない方法でキャッシュに影響を与える要求ヘッダーを設定できます。When testing and troubleshooting caching behavior, a browser may set request headers that affect caching in undesirable ways. たとえば、ページを更新するときに、ブラウザーで Cache-Control ヘッダーをまたはに設定でき no-cache max-age=0 ます。For example, a browser may set the Cache-Control header to no-cache or max-age=0 when refreshing a page. 次のツールでは、要求ヘッダーを明示的に設定でき、キャッシュのテストに適しています。The following tools can explicitly set request headers and are preferred for testing caching:

キャッシュの条件Conditions for caching

  • 要求は、200 (OK) 状態コードでサーバー応答を生成する必要があります。The request must result in a server response with a 200 (OK) status code.
  • 要求メソッドは GET または HEAD である必要があります。The request method must be GET or HEAD.
  • では Startup.Configure 、応答キャッシュミドルウェアは、キャッシュを必要とするミドルウェアの前に配置する必要があります。In Startup.Configure, Response Caching Middleware must be placed before middleware that require caching. 詳細については、「ASP.NET Core のミドルウェア」を参照してください。For more information, see ASP.NET Core のミドルウェア.
  • ヘッダーを指定することはでき Authorization ません。The Authorization header must not be present.
  • Cache-Control ヘッダーパラメーターは有効である必要があり、応答はとマークされている必要があり public private ます。Cache-Control header parameters must be valid, and the response must be marked public and not marked private.
  • ヘッダーが存在する場合、ヘッダーはヘッダーをオーバーライドするので、ヘッダーが存在しない場合はヘッダーが Pragma: no-cache 存在しない必要があり Cache-Control Cache-Control Pragma ます。The Pragma: no-cache header must not be present if the Cache-Control header isn't present, as the Cache-Control header overrides the Pragma header when present.
  • ヘッダーを指定することはでき Set-Cookie ません。The Set-Cookie header must not be present.
  • Vary ヘッダーパラメーターはと同じである必要があり * ます。Vary header parameters must be valid and not equal to *.
  • Content-Lengthヘッダー値 (設定されている場合) は、応答本文のサイズと一致する必要があります。The Content-Length header value (if set) must match the size of the response body.
  • IHttpSendFileFeature 使用されません。The IHttpSendFileFeature isn't used.
  • Expiresヘッダー、および、およびの各 max-age キャッシュディレクティブで指定されているとおり、応答を古いものにすることはできません s-maxageThe response must not be stale as specified by the Expires header and the max-age and s-maxage cache directives.
  • 応答バッファリングを成功させる必要があります。Response buffering must be successful. 応答のサイズは、構成済みまたは既定値よりも小さくする必要があり SizeLimit ます。The size of the response must be smaller than the configured or default SizeLimit. 応答の本文のサイズは、構成済みまたは既定値よりも小さくする必要があり MaximumBodySize ます。The body size of the response must be smaller than the configured or default MaximumBodySize.
  • 応答は、 RFC 7234 仕様に従ってキャッシュ可能である必要があります。The response must be cacheable according to the RFC 7234 specifications. たとえば、ディレクティブは、 no-store 要求または応答のヘッダーフィールドに存在することはできません。For example, the no-store directive must not exist in request or response header fields. 詳細については、 「セクション 3: RFC 7234 のキャッシュに応答を格納する」を参照してください。See Section 3: Storing Responses in Caches of RFC 7234 for details.

注意

クロスサイト要求偽造 (CSRF) 攻撃を防ぐために、セキュリティで保護されたトークンを生成するための偽造防止システムは、 Cache-Control Pragma 応答がキャッシュされないようにヘッダーとヘッダーをに設定し no-cache ます。The Antiforgery system for generating secure tokens to prevent Cross-Site Request Forgery (CSRF) attacks sets the Cache-Control and Pragma headers to no-cache so that responses aren't cached. HTML フォーム要素の偽造防止トークンを無効にする方法については、「」を参照してください ASP.NET Core でのクロスサイト要求偽造 (XSRF/CSRF) 攻撃を防ぐFor information on how to disable antiforgery tokens for HTML form elements, see ASP.NET Core でのクロスサイト要求偽造 (XSRF/CSRF) 攻撃を防ぐ.

その他のリソースAdditional resources