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.

옵션Options

응답 캐싱 옵션은 다음 표에 나와 있습니다.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" };
}

에서와 같은 단일 값을 사용 하는 경우 * 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
  • -인 경우에만 캐시only-if-cached
  • privateprivate
  • 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: 요청 캐시-제어 지시문을 참조 하십시오.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. 하나 이상의 쿠키를 설정 하는 요청 처리 파이프라인의 미들웨어는 응답 캐싱 미들웨어가 응답을 캐싱하는 것을 방지 합니다 (예: 쿠키 기반 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-Control .A 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 및 cache 지시문에 지정 된 대로 응답이 유효 하지 않아야 합니다 s-maxage .The 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-ControlPragma 응답이 캐시 되지 않도록 및 헤더를로 설정 합니다 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 메타 패키지 를 사용 하거나 ResponseCaching 패키지에 대 한 패키지 참조를 추가 합니다.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.

옵션Options

응답 캐싱 옵션은 다음 표에 나와 있습니다.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" };
}

에서와 같은 단일 값을 사용 하는 경우 * 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
  • -인 경우에만 캐시only-if-cached
  • privateprivate
  • 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: 요청 캐시-제어 지시문을 참조 하십시오.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. 하나 이상의 쿠키를 설정 하는 요청 처리 파이프라인의 미들웨어는 응답 캐싱 미들웨어가 응답을 캐싱하는 것을 방지 합니다 (예: 쿠키 기반 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-Control .A 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 및 cache 지시문에 지정 된 대로 응답이 유효 하지 않아야 합니다 s-maxage .The 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-ControlPragma 응답이 캐시 되지 않도록 및 헤더를로 설정 합니다 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