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

  • 아티클

존 루오와 릭 앤더슨 씀

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

응답 캐싱 미들웨어:

  • HTTP 캐시 헤더를 기반으로 서버 응답을 캐싱할 수 있도록 합니다. 표준 HTTP 캐싱 의미 체계를 구현합니다. 프록시처럼 HTTP 캐시 헤더에 기반하여 캐시합니다.
  • 브라우저는 일반적으로 캐싱을 방지하는 요청 헤더를 설정하기 때문에 Razor Pages와 같은 UI 앱에는 일반적으로 도움이 되지 않습니다. ASP.NET Core 7.0 이상에서 사용할 수 있는 출력 캐싱은 UI 앱에 이점을 제공합니다. 출력 캐싱을 사용하여 구성에서 HTTP 헤더와 독립적으로 캐시할 내용을 결정합니다.
  • 캐싱 조건이 충족되는 클라이언트의 퍼블릭 GET 또는 HEAD API 요청에 도움이 될 수 있습니다.

응답 캐싱을 테스트하려면 Fiddler 또는 요청 헤더를 명시적으로 설정할 수 있는 다른 도구를 사용합니다. 헤더를 명시적으로 설정하는 것은 캐싱을 테스트하는 데 선호됩니다. 자세한 내용은 문제 해결을 참조하십시오.

구성

Program.cs에서 서비스 컬렉션에 응답 캐싱 미들웨어 서비스 AddResponseCaching를 추가하고 앱을 구성하여 UseResponseCaching 확장 메서드와 함께 미들웨어를 사용하도록 합니다. UseResponseCaching은 요청 처리 파이프라인에 미들웨어를 추가합니다.

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddResponseCaching();

var app = builder.Build();

app.UseHttpsRedirection();

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

app.UseResponseCaching();

Warning

UseCors는 CORS 미들웨어를 사용하는 경우 UseResponseCaching 전에 호출되어야 합니다.

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

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

이전 헤더는 응답에 기록되지 않으며 컨트롤러, 작업 또는 Razor 페이지가 다음과 같은 경우 재정의됩니다.

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

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

Warning

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

이전 코드는 일반적으로 캐시된 값을 브라우저에 반환하지 않습니다. Fiddler, Postman 또는 요청 헤더를 명시적으로 설정할 수 있고 캐싱 테스트에 선호되는 다른 도구를 사용합니다. 자세한 내용은 이 문서의 문제 해결을 참조하세요.

옵션

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

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

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

  • 본문 크기가 1,024바이트 이하인 응답을 캐시합니다.
  • 대/소문자를 구분하는 경로별로 응답을 저장합니다. 예를 들어 /page1 및 /Page1은 별도로 저장됩니다.
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

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

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

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

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

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

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

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

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

자세한 내용은 RFC 9111: 요청 지시문을 참조하세요.
Pragma 요청의 Pragma: no-cache 헤더는 Cache-Control: no-cache와 동일한 효과를 생성합니다. 이 헤더는 Cache-Control 헤더의 관련 지시문(있는 경우)에 의해 재정의됩니다. HTTP/1.0의 이전 버전과의 호환성을 고려합니다.
Set-Cookie 헤더가 있으면 응답이 캐시되지 않습니다. 하나 이상의 cookie를 설정하는 요청 처리 파이프라인의 모든 미들웨어는 응답 캐싱 미들웨어가 응답을 캐시하지 못하게 합니다(예: cookie 기반 TempData 공급자).
Vary Vary 헤더는 캐시된 응답을 다른 헤더로 변경하는 데 사용됩니다. 예를 들어 헤더 Accept-Encoding: gzip 및 Accept-Encoding: text/plain이 있는 요청에 대한 응답을 별도로 캐시하는 Vary: Accept-Encoding 헤더를 포함하여 인코딩을 통해 응답을 캐시합니다. 헤더 값이 *인 응답은 저장되지 않습니다.
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 지시문을 준수합니다.

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

캐싱 동작을 더 잘 제어하려면 ASP.NET Core의 다른 캐싱 기능을 살펴보세요. 다음 항목을 참조하십시오.

문제 해결

응답 캐싱 미들웨어는 용량이 제한된 IMemoryCache를 사용합니다. 용량을 초과하면 메모리 캐시가 압축됩니다.

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

캐싱 동작을 테스트하고 문제를 해결할 때 브라우저는 일반적으로 캐싱을 방지하는 요청 헤더를 설정합니다. 예를 들어 브라우저는 페이지를 새로 고칠 때 Cache-Control 헤더를 no-cache 또는 max-age=0으로 설정할 수 있습니다. Fiddler, Postman 및 기타 도구는 요청 헤더를 명시적으로 설정할 수 있으며 캐싱 테스트에 선호됩니다.

캐싱 조건

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

참고 항목

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

추가 리소스

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

샘플 코드 보기 및 다운로드(다운로드 방법)

구성

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

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

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

Startup.Configure의 요청 처리 파이프라인에 미들웨어를 추가하는 UseResponseCaching 확장 메서드와 함께 미들웨어를 사용하도록 앱을 구성합니다.

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

Warning

UseCors는 CORS 미들웨어를 사용하는 경우 UseResponseCaching 전에 호출되어야 합니다.

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

  • Cache-Control: 캐시 가능한 응답을 최대 10초 동안 캐시합니다.
  • Vary: 후속 요청의 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(정상) 상태 코드를 발생시키는 서버 응답만 캐시합니다. 오류 페이지를 비롯한 다른 응답은 미들웨어에서 무시됩니다.

Warning

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

옵션

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

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

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

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

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

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

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

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

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

자세한 내용은 RFC 9111: 요청 지시문을 참조하세요.
Pragma 요청의 Pragma: no-cache 헤더는 Cache-Control: no-cache와 동일한 효과를 생성합니다. 이 헤더는 Cache-Control 헤더의 관련 지시문(있는 경우)에 의해 재정의됩니다. HTTP/1.0의 이전 버전과의 호환성을 고려합니다.
Set-Cookie 헤더가 있으면 응답이 캐시되지 않습니다. 하나 이상의 cookie를 설정하는 요청 처리 파이프라인의 모든 미들웨어는 응답 캐싱 미들웨어가 응답을 캐시하지 못하게 합니다(예: cookie 기반 TempData 공급자).
Vary Vary 헤더는 캐시된 응답을 다른 헤더로 변경하는 데 사용됩니다. 예를 들어 헤더 Accept-Encoding: gzip 및 Accept-Encoding: text/plain이 있는 요청에 대한 응답을 별도로 캐시하는 Vary: Accept-Encoding 헤더를 포함하여 인코딩을 통해 응답을 캐시합니다. 헤더 값이 *인 응답은 저장되지 않습니다.
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 지시문을 준수합니다.

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

캐싱 동작을 더 잘 제어하려면 ASP.NET Core의 다른 캐싱 기능을 살펴보세요. 다음 항목을 참조하십시오.

문제 해결

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

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

캐싱 조건

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

참고 항목

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

추가 리소스