다음을 통해 공유


Internet Explorer에서 캐싱을 방지하는 방법

Warning

사용과 지원이 중단된 Internet Explorer 11 데스크톱 애플리케이션이 Microsoft Edge 업데이트를 통해 특정 버전의 Windows 10에서 영구적으로 비활성화될 예정입니다. 자세한 내용은 Internet Explorer 11 데스크톱 앱 지원 중단 FAQ를 참조하세요.

이 문서에서는 HTTP 헤더를 사용하여 Internet Explorer에서 웹 페이지의 캐싱을 제어하는 방법을 설명합니다.

원래 제품 버전: Internet Explorer
원래 KB 번호: 234067

요약

Microsoft IIS(인터넷 정보 서버)를 사용하여 특정 ASP(Active Server Pages) 페이지의 시작 부분에서 다음 스크립트를 사용하여 매우 휘발성이 높거나 중요한 페이지를 쉽게 표시할 수 있습니다.

<% Response.CacheControl = "no-cache" %>
<% Response.AddHeader "Pragma", "no-cache" %>
<% Response.Expires = -1 %>

만료 및 만료 헤더

모든 웹 서버는 모든 웹 페이지의 만료를 위해 체계를 사용하는 것이 좋습니다. 웹 서버가 요청 클라이언트에 반환된 모든 리소스에 대해 HTTP 만료 응답 헤더를 통해 만료 정보를 제공하지 않는 것은 잘못된 방법입니다. 오늘날 대부분의 브라우저 및 중간 프록시는 이 만료 정보를 존중하고 이를 사용하여 네트워크를 통한 통신의 효율성을 높입니다.

클라이언트에서 서버의 특정 파일을 업데이트해야 하는 가장 적절한 시간을 지정하려면 항상 Expires 헤더를 사용합니다. 페이지가 정기적으로 업데이트되는 경우 다음 업데이트 기간은 가장 효율적인 응답입니다. 예를 들어 매일 오전 5시에 업데이트되는 인터넷의 일일 뉴스 페이지를 예로 들어보십시오. 이 뉴스 페이지의 웹 서버는 다음 날 오전 5시에 값이 있는 Expires 헤더를 반환해야 합니다. 완료되면 페이지가 변경될 때까지 브라우저에서 웹 서버에 다시 연결할 필요가 없습니다.

변경될 것으로 예상되지 않는 페이지는 만료 날짜가 약 1년으로 표시되어야 합니다.

대부분의 경우 웹 서버에는 즉시 변경될 수 있는 정보가 포함된 하나 이상의 휘발성 페이지가 서버에 있습니다. 이러한 페이지는 만료 헤더의 값이 "-1"인 서버에서 표시해야 합니다. 사용자의 향후 요청에서 Internet Explorer는 일반적으로 조건부 If-Modified-Since 요청을 통해 웹 서버에 연결하여 해당 페이지에 대한 업데이트를 요청합니다. 그러나 페이지는 디스크 캐시(임시 인터넷 파일)에 남아 있습니다. 그리고 이 페이지는 다음과 같은 원격 웹 서버에 연결하지 않고 적절한 상황에서 사용됩니다.

  • 뒤로 및 앞으로 단추를 사용하여 탐색 기록에 액세스할 때
  • 브라우저가 오프라인 모드인 경우

Cache-Control 헤더

그러나 특정 페이지는 너무 휘발성이거나 민감하여 디스크 캐싱이 필요하지 않습니다. 이를 위해 Internet Explorer는 HTTP 1.1 Cache-Control 헤더를 지원합니다. 이 헤더는 HTTP 1.1 서버에서 no-cache 값을 지정하는 경우 특정 웹 리소스의 모든 캐싱을 방지합니다.

브라우저에서 웹 서버를 다시 연결할 수 있기 전까지는 캐시에서 유지되는 페이지에 액세스할 수 없습니다. 따라서 서버는 Cache-Control 헤더를 아쉽게 사용해야 합니다. 대부분의 경우 만료: -1을 사용하는 것이 좋습니다.

Pragma: No-Cache 헤더

아쉽게도 레거시 HTTP 1.0 서버는 Cache-Control 헤더를 사용할 수 없습니다. 이전 버전의 HTTP 1.0 서버와의 호환성을 위해 Internet Explorer는 HTTP Pragma: no-cache 헤더의 특수 사용을 지원합니다. 클라이언트가 보안 연결(https://)을 통해 서버와 통신하고 서버가 Pragma: 응답이 있는 no-cache 헤더를 반환하는 경우 Internet Explorer는 응답을 캐시하지 않습니다.

그러나 Pragma: no-cache 헤더는 이 용도가 아니었습니다. HTTP 1.0 및 1.1 사양에 따라 이 헤더는 응답이 아닌 요청 컨텍스트에서만 정의됩니다. 특정 중요한 요청이 대상 웹 서버에 도달하지 못하게 할 수 있는 프록시 서버를 위한 것입니다. 향후 애플리케이션의 경우 캐시 제어 헤더는 캐싱을 제어하기 위한 적절한 수단입니다.

HTTP-EQUIV META 태그

HTML 페이지에서는 HTML 문서 내에서 특정 HTTP 헤더를 지정하는 META 태그의 특수 HTTP-EQUIV 형식을 사용할 수 있습니다. 다음은 Pragma: no-cache 및 Expires: -1을 모두 사용하는 간단한 HTML 페이지입니다.

<HTML>
    <HEAD>
        <META HTTP-EQUIV="Pragma" CONTENT="no-cache">
        <META HTTP-EQUIV="Expires" CONTENT="-1">
    </HEAD>
<BODY>
</BODY>
</HTML>

Pragma: no-cache는 보안 연결을 통해 사용되는 경우에만 캐싱을 방지합니다. Pragma: 비캐시 META 태그는 안전하지 않은 페이지에서 사용되는 경우 만료: -1과 동일하게 처리됩니다. 페이지가 캐시되지만 즉시 만료된 것으로 표시됩니다.

Cache-Control META HTTP-EQUIV 태그는 무시되며 Internet Explorer 버전 4 또는 5에는 영향을 주지 않습니다. Cache-Control을 사용하려면 위의 Cache-Control 섹션에 설명된 대로 HTTP 헤더를 사용하여 이 헤더를 지정해야 합니다.

참고 항목

표준 HTTP 헤더를 사용하는 것이 META 태그보다 훨씬 선호됩니다. META 태그는 일반적으로 HTML HEAD 섹션의 맨 위에 표시되어야 합니다. Pragma HTTP-EQUIV META 태그에는 알려진 문제가 하나 이상 있습니다.

캐싱을 위한 서버 옵션

ASP가 아닌 페이지에서 Cache-Control 헤더를 사용해야 하는 경우 서버 구성의 옵션을 사용하여 이 헤더를 자동으로 추가해야 할 수 있습니다. 특정 디렉터리에 대한 서버 응답에 HTTP 헤더를 추가하는 프로세스는 서버 문서를 참조하세요. 예를 들어 IIS 4에서 다음 단계를 수행합니다.

  1. IIS 관리자를 시작합니다.
  2. 컴퓨터 및 서비스 트리에서 기본 웹 서버 또는 해당 웹 서버를 엽니다. Cache-Control 헤더가 필요한 콘텐츠가 포함된 디렉터리를 찾습니다.
  3. 해당 디렉터리에 대한 속성 대화 상자를 엽니다.
  4. HTTP 헤더 탭을 선택합니다.
  5. 사용자 지정 HTTP 헤더 그룹에서 추가 단추를 선택하고 헤더 이름에 대한 Cache-Control과 헤더 값에 대한 no-cache를 추가합니다.

전체 웹 서버에서 이 헤더를 전역적으로 사용하는 것은 좋지 않습니다. 클라이언트에서 절대로 캐시해서는 안 되는 콘텐츠로만 사용을 제한합니다.

문제 검사 목록

이 문서의 기술을 적용했으며 여전히 캐싱 및 Internet Explorer에 문제가 있는 경우 Microsoft에 기술 지원 지원을 요청하기 전에 이 편리한 검사 목록을 단계별로 검토하세요.

  • ASP Response.CacheControl 속성 또는 반환된 HTTP 헤더를 통해 Cache-Control 헤더를 사용하고 있나요? Internet Explorer에서 캐싱을 진정으로 방지하는 유일한 방법입니다.
  • Internet Explorer 4.01 서비스 팩 2 이상을 사용하고 있나요? 이전 버전의 브라우저에서 캐싱을 완전히 방지할 수 있는 방법은 없습니다.
  • 웹 서버에 HTTP 1.1이 켜져 있고 Internet Explorer에 HTTP 1.1 응답을 반환하고 있는지 다시 확인했나요? HTTP 1.0 응답에서 Cache-Control 헤더가 잘못되었습니다.
  • 서버 쪽에서 CGI/ISAPI/Servlet을 사용하는 경우 HTTP 헤더의 CRLF 종료에 대해 HTTP 1.1 사양을 정확하게 따르고 있나요? 성능을 위해 Internet Explorer는 일반적으로 HTTP 1.1 사양을 위반하는 응답을 용서하지 않습니다. 일반적으로 헤더가 무시되거나 예기치 않은 서버 오류가 보고됩니다.
  • HTTP 헤더의 철자가 올바릅니다.

참고 항목