다양한 유형의 리소스에 이상적인 HTTP 캐시 제어 헤더

"모든"캐시 및 브라우저에서 작동하는 최소한의 헤더 세트를 찾고 싶습니다 ( HTTPS를 사용할 때도 마찬가지입니다 !).

내 웹 사이트에는 세 가지 종류의 리소스가 있습니다.

(1) 영구 캐시 가능 (공개 / 모든 사용자에 대해 동일)

^{예 : 0A470E87CC58EE133616F402B5DDFE1C.cache.html ( GWT에 의해 자동 생성됨 )}

• 이러한 파일은 콘텐츠가 변경 될 때 자동으로 새 이름이 지정됩니다 (MD5 기준).

• HTTPS를 사용하는 경우에도 가능한 한 많이 캐시되어야합니다 (그래서 Cache-Control: public특히 Firefox의 경우를 설정해야한다고 가정합니다 .)

• 콘텐츠가 변경된 경우 클라이언트가 유효성을 검사하기 위해 서버로 왕복 할 필요가 없습니다.

(2) 가끔 변경 (공개 / 모든 사용자에 대해 동일)

^{예 : index.html, mymodule.nocache.js}

• 이러한 파일은 사이트의 새 버전이 배포 될 때 URL을 변경하지 않고 콘텐츠를 변경합니다.

• 캐시 할 수 있지만 매번 유효성을 다시 확인하려면 왕복이 필요할 수 있습니다.

(3) 각 요청에 대한 개별 (개인 / 사용자 별)

^{예 : JSON 응답}

• 이러한 리소스는 어떠한 경우에도 암호화되지 않은 상태로 디스크에 캐시되어서는 안됩니다. (캐시 될 수있는 몇 가지 특정 요청이있을 수 있습니다.)

각 유형에 대해 어떤 헤더를 사용할 지에 대한 일반적인 아이디어가 있지만 항상 누락 될 수있는 것이 있습니다.

아마도 다음 설정을 사용합니다.

1. Cache-Control: max-age=31556926– 표현은 모든 캐시에 의해 캐시 될 수 있습니다. 캐시 된 표현은 1 년 동안 새로운 것으로 간주됩니다.

   응답을 "만료되지 않음"으로 표시하기 위해 오리진 서버는 응답이 전송 된 후 약 1 년 후에 만료 날짜를 보냅니다. HTTP / 1.1 서버는 향후 1 년 이상 만료 날짜를 보내면 안됩니다.

2. Cache-Control: no-cache– 모든 캐시에서 표현을 캐시 할 수 있습니다. 그러나 캐시는 캐시 된 복사본을 릴리스하기 전에 유효성 검사를 위해 원본 서버에 요청을 제출해야합니다.
3. Cache-Control: no-store – 캐시는 어떤 조건에서도 표현을 캐시해서는 안됩니다.

자세한 내용은 Mark Nottingham의 캐싱 자습서 를 참조하십시오 .

사례 1과 2는 실제로 동일한 시나리오입니다. Cache-Control: public사이트의 빌드 번호 / 버전이 포함 된 URL을 설정 하고 생성하여 잠재적으로 영원히 지속될 수있는 변경 불가능한 리소스를 갖도록해야합니다. 또한 Expires클라이언트가 최신 성 검사를 발행 할 필요가 없도록 헤더를 1 년 이상 앞으로 설정하려고합니다 .

사례 3의 경우 최대 유연성을 위해 다음을 모두 수행 할 수 있습니다.

"Cache-Control", "no-cache, must-revalidate"
"Expires", 0
"Pragma", "no-cache"