ASP.NET Core의 응답 캐싱 미들웨어

작성자: John Luo

이 문서에서는 ASP.NET Core 앱에서 응답 캐싱 미들웨어를 구성 하는 방법을 설명 합니다. 미들웨어는 응답을 캐시할 시기를 결정 하 고, 응답을 저장 하 고, 캐시에서 응답을 제공 합니다. HTTP 캐싱 및 특성에 대 한 소개는 [ResponseCache] 응답 캐싱을 참조 하세요.

예제 코드 살펴보기 및 다운로드 (다운로드 방법)

Configuration

응답 캐싱 미들웨어는 공유 프레임 워크를 통해 ASP.NET Core 앱에 대해 암시적으로 사용할 수 있습니다.

에서 Startup.ConfigureServices 응답 캐싱 미들웨어를 서비스 컬렉션에 추가 합니다.

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

UseResponseCaching의 요청 처리 파이프라인에 미들웨어를 추가 하는 확장 메서드를 사용 하 여 미들웨어를 사용 하도록 앱을 구성 합니다 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 미들웨어를 사용 하는 경우 먼저를 호출 해야 합니다.

샘플 앱은 다음 요청에 대 한 캐싱을 제어 하는 헤더를 추가 합니다.

  • Cache-control: 최대 10 초 동안 캐시할 수 있는 응답을 캐시 합니다.
  • Vary: 후속 요청의 수락 인코딩 헤더가 원래 요청과 일치 하는 경우에만 캐시 된 응답을 제공 하도록 미들웨어를 구성 합니다.
// 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 .

  • 에는 [ResponseCache] 특성이 있습니다. 속성이 설정 되지 않은 경우에도 마찬가지입니다. 예를 들어 Varybyheader 속성을 생략 하면 해당 헤더가 응답에서 제거 됩니다.

응답 캐싱 미들웨어는 200 (OK) 상태 코드를 발생 시키는 서버 응답만 캐시 합니다. 오류 페이지를 비롯 한 다른 모든 응답은 미들웨어에서 무시 됩니다.

경고

인증 된 클라이언트에 대 한 콘텐츠를 포함 하는 응답은 미들웨어가 해당 응답을 저장 및 제공 하지 못하도록 캐시할 수 없음으로 표시 되어야 합니다. 미들웨어가 응답을 캐시할 수 있는지 여부를 결정 하는 방법에 대 한 자세한 내용은 캐싱에 대 한 조건을 참조 하세요.

옵션

응답 캐싱 옵션은 다음 표에 표시됩니다.

옵션 Description
MaximumBodySize 응답 본문의 캐시 가능한 최대 크기(바이트)입니다. 기본값은 64 * 1024 * 1024 (64MB)입니다.
SizeLimit 응답 캐시 미들웨어의 크기 제한(바이트)입니다. 기본값은 100 * 1024 * 1024 (100MB)입니다.
UseCaseSensitivePaths 대/소문자를 구분하는 경로에 응답이 캐시되는지 여부를 결정합니다. 기본값은 false입니다.

다음 예제에서는 미들웨어를 다음으로 구성합니다.

  • 본문 크기가 1,024바이트보다 작거나 같은 응답을 캐시합니다.
  • 대/소문자를 구분하는 경로별로 응답을 저장합니다. 예를 들어 /page1 및 는 별도로 /Page1 저장됩니다.
services.AddResponseCaching(options =>
{
    options.MaximumBodySize = 1024;
    options.UseCaseSensitivePaths = true;
});

VaryByQueryKeys

MVC/웹 API 컨트롤러 또는 Pages 페이지 모델을 사용하는 경우 Razor [ResponseCache] 특성은 응답 캐싱에 적절한 헤더를 설정하는 데 필요한 매개 변수를 지정합니다. 미들웨어를 엄격하게 요구하는 특성의 유일한 매개 [ResponseCache] 변수는 VaryByQueryKeys 실제 HTTP 헤더에 해당하지 않는 입니다. 자세한 내용은 ASP.NET Core의 응답 캐싱를 참조하세요.

특성을 사용하지 않는 경우 를 사용하여 [ResponseCache] 응답 캐싱을 변경할 수 VaryByQueryKeys 있습니다. ResponseCachingFeature HttpContext.Features에서 직접 를 사용합니다.

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

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

에 같은 단일 값을 사용하면 * 모든 요청 쿼리 매개 VaryByQueryKeys 변수에 따라 캐시가 달라집니다.

응답 캐싱 미들웨어에서 사용하는 HTTP 헤더

다음 표에서는 응답 캐싱에 영향을 주는 HTTP 헤더에 대한 정보를 제공합니다.

헤더 세부 정보
Authorization 헤더가 있으면 응답이 캐시되지 않습니다.
Cache-Control 미들웨어는 캐시 지시문으로 표시된 캐싱 응답만 public 고려합니다. 다음 매개 변수를 사용 하 여 캐싱 제어:
  • 최대 사용 기간
  • 최대-오래 된†
  • 최소-새로
  • must-revalidate
  • no-cache
  • 저장소 없음
  • -인 경우에만 캐시
  • private
  • public
  • s-maxage
  • 프록시-유효성 검사‡
†에 대 한 제한이 지정 되지 않은 경우 max-stale 미들웨어는 아무 작업도 수행 하지 않습니다.
‡는 proxy-revalidate 와 동일한 효과가 있습니다 must-revalidate .

자세한 내용은 RFC 7231: Request Cache-Control 지시문을 참조 하십시오.
Pragma Pragma: no-cache요청의 헤더는와 동일한 결과를 생성 Cache-Control: no-cache 합니다. 이 헤더는 헤더의 관련 지시문 (있는 경우)에 의해 재정의 됩니다 Cache-Control . HTTP/1.0과의 이전 버전과의 호환성을 고려 합니다.
Set-Cookie 헤더가 있으면 응답이 캐시 되지 않습니다. 하나 이상의를 설정 하는 요청 처리 파이프라인의 미들웨어는 응답 cookie 캐싱 미들웨어가 응답을 캐싱하는 것을 방지 합니다 (예: cookie 기반 TempData 공급자).
Vary Vary헤더는 다른 헤더로 캐시 된 응답을 변경 하는 데 사용 됩니다. 예를 들어 헤더를 포함 하 여 인코딩을 통해 응답을 캐시 하 고 헤더를 포함 하 Vary: Accept-Encoding 는 요청에 대 한 응답을 캐시 합니다 Accept-Encoding: gzip Accept-Encoding: text/plain . 헤더 값이 인 응답은 * 저장 되지 않습니다.
Expires 이 헤더에 의해 부실 하 게 간주 되는 응답은 다른 헤더로 재정의 되지 않는 한 저장 되거나 검색 되지 않습니다 Cache-Control .
If-None-Match 값이이 *ETag 응답의이 제공 된 값과 일치 하지 않는 경우 전체 응답이 캐시에서 제공 됩니다. 그렇지 않으면 304 (수정 되지 않음) 응답이 제공 됩니다.
If-Modified-Since 헤더가 없으면 캐시 된 If-None-Match 응답 날짜가 제공 된 값 보다 최신인 경우 전체 응답이 캐시에서 제공 됩니다. 그렇지 않으면 304 수정 되지 않은 응답이 제공 됩니다.
Date 캐시에서 서비스를 제공 하는 경우 Date 헤더는 원래 응답에서 제공 되지 않은 경우 미들웨어에 의해 설정 됩니다.
Content-Length 캐시에서 서비스를 제공 하는 경우 Content-Length 헤더는 원래 응답에서 제공 되지 않은 경우 미들웨어에 의해 설정 됩니다.
Age Age원래 응답에서 보낸 헤더는 무시 됩니다. 미들웨어는 캐시 된 응답을 제공할 때 새 값을 계산 합니다.

캐싱 측면 요청 Cache-Control 지시문

미들웨어는 HTTP 1.1 캐싱 사양의규칙을 고려 합니다. 규칙에는 클라이언트가 보낸 유효한 헤더를 인식 하기 위해 캐시가 필요 Cache-Control 합니다. 사양에 따라 클라이언트는 헤더 값을 사용 하 여 요청을 수행 하 no-cache 고 서버에서 모든 요청에 대 한 새 응답을 생성 하도록 강제할 수 있습니다. 현재 미들웨어는 공식 캐싱 사양을 준수 하므로 미들웨어를 사용할 때이 캐싱 동작에 대 한 개발자 제어는 없습니다.

캐싱 동작을 보다 세부적으로 제어 하려면 ASP.NET Core의 다른 캐싱 기능을 살펴봅니다. 다음 항목을 참조하세요.

문제 해결

캐싱 동작이 예상과 다른 경우 응답이 캐시 가능 하 고 캐시에서 제공 될 수 있는지 확인 합니다. 요청의 들어오는 헤더와 응답의 나가는 헤더를 검사 합니다. 디버깅에 도움이 되는 로깅을 사용 합니다.

캐싱 동작을 테스트 하 고 문제를 해결할 때 브라우저는 원치 않는 방식으로 캐싱에 영향을 주는 요청 헤더를 설정할 수 있습니다. 예를 들어, 브라우저에서 페이지를 Cache-Control no-cache 새로 고칠 때 헤더를 또는로 설정할 수 있습니다 max-age=0 . 다음 도구는 명시적으로 요청 헤더를 설정할 수 있으며 캐싱을 테스트 하는 데 기본 설정 됩니다.

캐싱 조건

  • 요청은 200 (OK) 상태 코드를 포함 하는 서버 응답을 생성 해야 합니다.
  • 요청 메서드는 GET 또는 HEAD 여야 합니다.
  • 에서 Startup.Configure 캐싱은 캐싱을 필요로 하는 미들웨어 앞에 배치 해야 합니다. 자세한 내용은 ASP.NET Core 미들웨어 기본 사항를 참조하세요.
  • 헤더가 없어야 합니다 Authorization .
  • Cache-Control 헤더 매개 변수는 유효 해야 하 고 응답은 표시 되 public 고 표시 되지 않아야 합니다 private .
  • 헤더가 있을 Pragma: no-cache Cache-Control 때 헤더가 헤더를 재정의 하므로 헤더가 없으면 헤더가 없어야 합니다 Cache-Control Pragma .
  • 헤더가 없어야 합니다 Set-Cookie .
  • Vary 헤더 매개 변수는 유효 해야 하 고와 같지 않아야 합니다 * .
  • Content-Length헤더 값 (설정 된 경우)은 응답 본문의 크기와 일치 해야 합니다.
  • IHttpSendFileFeature 사용 되지 않습니다.
  • Expires헤더와 max-age 및 cache 지시문에 지정 된 대로 응답이 유효 하지 않아야 합니다 s-maxage .
  • 응답 버퍼링이 성공 해야 합니다. 응답의 크기는 구성 된 또는 기본값 보다 작아야 합니다 SizeLimit . 응답의 본문 크기는 구성 된 또는 기본값 보다 작아야 합니다 MaximumBodySize .
  • RFC 7234 사양에 따라 응답을 캐시할 수 있어야 합니다. 예를 들어 no-store 지시문은 요청 또는 응답 헤더 필드에 없어야 합니다. 자세한 내용은 섹션 3: RFC 7234캐시에 응답 저장 을 참조 하세요.

참고

CSRF (교차 사이트 요청 위조) 공격을 방지 하기 위해 보안 토큰을 생성 하는 위조 방지 시스템 Cache-ControlPragma 응답이 캐시 되지 않도록 및 헤더를로 설정 합니다 no-cache . HTML 양식 요소의 위조 방지 토큰을 사용 하지 않도록 설정 하는 방법에 대 한 자세한 내용은을 참조 하십시오 ASP.NET Core에서 교차 사이트 요청 위조 (XSRF/CSRF) 공격 방지 .

추가 자료

이 문서에서는 ASP.NET Core 앱에서 응답 캐싱 미들웨어를 구성하는 방법을 설명합니다. 미들웨어는 응답이 캐시 가능한 시기를 확인하고, 응답을 저장하고, 캐시에서 응답을 제공합니다. HTTP 캐싱 및 특성에 대한 소개는 [ResponseCache] 응답 캐싱을 참조하세요.

예제 코드 살펴보기 및 다운로드 (다운로드 방법)

Configuration

Microsoft.AspNetCore.App 메타패키지를 사용하거나 Microsoft.AspNetCore.ResponseCaching 패키지에 패키지 참조를 추가합니다.

에서 Startup.ConfigureServices 응답 캐싱 미들웨어를 서비스 컬렉션에 추가합니다.

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

의 요청 처리 파이프라인에 미들웨어를 추가하는 확장 메서드와 함께 미들웨어를 사용하도록 앱을 UseResponseCaching 구성합니다. 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();
}

샘플 앱은 후속 요청에 대한 캐싱을 제어하는 헤더를 추가합니다.

  • Cache-Control:캐시 가능한 응답을 최대 10초 동안 캐시합니다.
  • Vary:후속 요청의 Accept-Encoding 헤더가 원래 요청의 Accept-Encoding 헤더와 일치하는 경우에만 캐시된 응답을 제공하도록 미들웨어를 구성합니다.
// 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

  • [ResponseCache] 특성이 있습니다. 이는 속성이 설정되지 않은 경우에도 적용됩니다. 예를 들어 VaryByHeader 속성을 생략하면 해당 헤더가 응답에서 제거됩니다.

응답 캐싱 미들웨어는 200(정상) 상태 코드를 발생시키는 서버 응답만 캐시합니다. 오류 페이지를비롯한 다른 응답은 미들웨어에서 무시됩니다.

경고

인증된 클라이언트에 대한 콘텐츠가 포함된 응답은 미들웨어가 해당 응답을 저장하고 제공하지 못하도록 캐시할 수 없는 것으로 표시되어야 합니다. 미들웨어에서 응답을 캐시할 수 있는지 확인하는 방법에 대한 자세한 내용은 캐싱 조건을 참조하세요.

옵션

응답 캐싱 옵션은 다음 표에 표시됩니다.

옵션 Description
MaximumBodySize 응답 본문의 캐시 가능한 최대 크기(바이트)입니다. 기본값은 64 * 1024 * 1024 (64MB)입니다.
SizeLimit 응답 캐시 미들웨어의 크기 제한 (바이트)입니다. 기본값은 100 * 1024 * 1024 (100 MB)입니다.
UseCaseSensitivePaths 대/소문자를 구분 하는 경로에서 응답이 캐시 되는지 여부를 결정 합니다. 기본값은 false입니다.

다음 예제에서는 미들웨어를 구성 합니다.

  • 본문 크기가 1024 바이트 보다 작거나 같은 응답을 캐시 합니다.
  • 대/소문자 구분 경로를 기준으로 응답을 저장 합니다. 예를 들어 /page1/Page1 은 별도로 저장 됩니다.
services.AddResponseCaching(options =>
{
    options.MaximumBodySize = 1024;
    options.UseCaseSensitivePaths = true;
});

VaryByQueryKeys

MVC/web API 컨트롤러 또는 Razor 페이지 페이지 모델을 사용 하는 경우 [ResponseCache] 특성은 응답 캐싱에 적합 한 헤더를 설정 하는 데 필요한 매개 변수를 지정 합니다. [ResponseCache]미들웨어를 엄격히 필요로 하는 특성의 유일한 매개 변수는 VaryByQueryKeys 실제 HTTP 헤더에 해당 하지 않습니다. 자세한 내용은 ASP.NET Core의 응답 캐싱를 참조하세요.

특성을 사용 하지 않는 경우 [ResponseCache] 응답 캐싱은에서 달라질 수 있습니다 VaryByQueryKeys . ResponseCachingFeature다음과 같이 HttpContext에서 직접를 사용 합니다.

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

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

에서와 같은 단일 값을 사용 하는 경우 * VaryByQueryKeys 모든 요청 쿼리 매개 변수에 의해 캐시가 달라 집니다.

응답 캐싱 미들웨어에서 사용 하는 HTTP 헤더

다음 표에서는 응답 캐싱에 영향을 주는 HTTP 헤더에 대 한 정보를 제공 합니다.

헤더 세부 정보
Authorization 헤더가 있으면 응답이 캐시 되지 않습니다.
Cache-Control 미들웨어는 cache 지시문으로 표시 된 캐싱 응답만 고려 합니다 public . 다음 매개 변수를 사용 하 여 캐싱 제어:
  • 최대 사용 기간
  • 최대-오래 된†
  • min-fresh
  • must-revalidate
  • no-cache
  • no-store
  • only-if-cached
  • private
  • public
  • s-maxage
  • proxy-revalidate‡
†에 제한이 지정되지 않은 경우 max-stale 미들웨어는 아무 작업도 수행하지 않습니다.
proxy-revalidate 의 효과는 must-revalidate 입니다.

자세한 내용은 RFC 7231: 요청 Cache-Control 지시문을 참조하세요.
Pragma Pragma: no-cache요청의 헤더는 같은 효과를 Cache-Control: no-cache 생성합니다. 이 헤더는 헤더의 관련 지시문(있는 Cache-Control 경우)에 의해 재정의됩니다. HTTP/1.0과의 이전 버전과의 호환성을 고려합니다.
Set-Cookie 헤더가 있으면 응답이 캐시되지 않습니다. 하나 이상의 를 설정하는 요청 처리 파이프라인의 모든 cookie 미들웨어는 응답 캐싱 미들웨어가 응답을 캐시하지 못하게 합니다(예: cookie 기반 TempData 공급자).
Vary Vary헤더는 다른 헤더에 의해 캐시된 응답을 다양하게 하는 데 사용됩니다. 예를 들어 헤더를 포함하여 인코딩을 통해 응답을 캐시합니다. 이 헤더는 Vary: Accept-Encoding 헤더 및 를 사용하여 요청에 대한 응답을 개별적으로 캐시합니다. Accept-Encoding: gzip Accept-Encoding: text/plain 헤더 값이 인 * 응답은 저장되지 않습니다.
Expires 이 헤더에서 부실한 것으로 간주되는 응답은 다른 헤더에 의해 재정의되지 않는 한 저장되거나 검색되지 Cache-Control 않습니다.
If-None-Match 값이 이 아니고 응답의 가 제공된 값과 일치하지 않는 경우 캐시에서 전체 * ETag 응답이 제공됩니다. 그렇지 않으면 304(수정되지 않음) 응답이 제공됩니다.
If-Modified-Since If-None-Match헤더가 없으면 캐시된 응답 날짜가 제공된 값보다 최신인 경우 캐시에서 전체 응답이 제공됩니다. 그렇지 않으면 304 수정 되지 않은 응답이 제공 됩니다.
Date 캐시에서 서비스를 제공 하는 경우 Date 헤더는 원래 응답에서 제공 되지 않은 경우 미들웨어에 의해 설정 됩니다.
Content-Length 캐시에서 서비스를 제공 하는 경우 Content-Length 헤더는 원래 응답에서 제공 되지 않은 경우 미들웨어에 의해 설정 됩니다.
Age Age원래 응답에서 보낸 헤더는 무시 됩니다. 미들웨어는 캐시 된 응답을 제공할 때 새 값을 계산 합니다.

캐싱 측면 요청 Cache-Control 지시문

미들웨어는 HTTP 1.1 캐싱 사양의규칙을 고려 합니다. 규칙에는 클라이언트가 보낸 유효한 헤더를 인식 하기 위해 캐시가 필요 Cache-Control 합니다. 사양에 따라 클라이언트는 헤더 값을 사용 하 여 요청을 수행 하 no-cache 고 서버에서 모든 요청에 대 한 새 응답을 생성 하도록 강제할 수 있습니다. 현재 미들웨어는 공식 캐싱 사양을 준수 하므로 미들웨어를 사용할 때이 캐싱 동작에 대 한 개발자 제어는 없습니다.

캐싱 동작을 보다 세부적으로 제어 하려면 ASP.NET Core의 다른 캐싱 기능을 살펴봅니다. 다음 항목을 참조하세요.

문제 해결

캐싱 동작이 예상과 다른 경우 응답이 캐시 가능 하 고 캐시에서 제공 될 수 있는지 확인 합니다. 요청의 들어오는 헤더와 응답의 나가는 헤더를 검사 합니다. 디버깅에 도움이 되는 로깅을 사용 합니다.

캐싱 동작을 테스트 하 고 문제를 해결할 때 브라우저는 원치 않는 방식으로 캐싱에 영향을 주는 요청 헤더를 설정할 수 있습니다. 예를 들어, 브라우저에서 페이지를 Cache-Control no-cache 새로 고칠 때 헤더를 또는로 설정할 수 있습니다 max-age=0 . 다음 도구는 명시적으로 요청 헤더를 설정할 수 있으며 캐싱을 테스트 하는 데 기본 설정 됩니다.

캐싱 조건

  • 요청은 200 (OK) 상태 코드를 포함 하는 서버 응답을 생성 해야 합니다.
  • 요청 메서드는 GET 또는 HEAD 여야 합니다.
  • 에서 Startup.Configure 응답 캐싱 미들웨어는 캐싱이 필요한 미들웨어 앞에 배치해야 합니다. 자세한 내용은 ASP.NET Core 미들웨어 기본 사항를 참조하세요.
  • Authorization헤더가 없어야 합니다.
  • Cache-Control 헤더 매개 변수는 유효해야 하며 응답은 로 표시되고 public 표시되지 않아야 private 합니다.
  • 헤더가 없는 경우 헤더가 있으면 헤더가 헤더를 Pragma: no-cache Cache-Control 재정의하기 때문에 헤더가 없어야 Cache-Control Pragma 합니다.
  • Set-Cookie헤더가 없어야 합니다.
  • Vary 헤더 매개 변수는 유효해야 하며 와 같지 않아야 * 합니다.
  • Content-Length헤더 값(설정된 경우)은 응답 본문의 크기와 일치해야 합니다.
  • IHttpSendFileFeature 사용되지 않습니다.
  • 응답은 Expires 헤더 및 및 캐시 max-age 지시문에 지정된 대로 부실하지 않아야 s-maxage 합니다.
  • 응답 버퍼링이 성공해야 합니다. 응답 크기는 구성된 또는 기본 보다 작아야 SizeLimit 합니다. 응답의 본문 크기는 구성된 또는 기본 보다 작아야 MaximumBodySize 합니다.
  • 응답은 RFC 7234 사양에 따라 캐시할 수 있어야 합니다. 예를 들어 no-store 지시문은 요청 또는 응답 헤더 필드에 없어야 합니다. 자세한 내용은 섹션 3: RFC 7234의 캐시에 응답 저장을 참조하세요.

참고

CSRF(교차 사이트 요청 위조) 공격을 방지하기 위해 보안 토큰을 생성하기 위한 위조 방지 시스템은 Cache-Control Pragma 응답이 캐시되지 않도록 및 헤더를 로 no-cache 설정합니다. HTML 양식 요소에 위조 방지 토큰을 사용하지 않도록 설정하는 방법에 대한 자세한 내용은 를 ASP.NET Core에서 교차 사이트 요청 위조 (XSRF/CSRF) 공격 방지 참조하세요.

추가 자료