캐시 제어의 기본값은 무엇입니까?

Question

내 문제는 : 브라우저가 일부 리소스를 이미 수정 한 경우에도 캐시 된 경우가 있습니다. 그러나 F5 이후 모든 것이 좋습니다.

나는 오후 내내이 사건을 연구했다. 이제는 "Last-Modified"또는 "Cache-Control"의 요점을 완전히 이해했습니다. 그리고 내 문제 (그냥 .js? 버전 또는 명시 적 최대 연령 = xxxx)을 해결하는 방법을 알고 있습니다.

"바에서 입력"때

Content-Length: 49675 
Content-Type: text/html 
Last-Modified: Thu, 27 Dec 2012 03:03:50 GMT 
Accept-Ranges: bytes 
Etag: "0af7fcbdee3cd1:972" 
Server: Microsoft-IIS/6.0 
X-Powered-By: ASP.NET 
Date: Thu, 24 Jan 2013 07:46:16 GMT 

그들은 명확하게 캐시 : 브라우저가이 같은 "캐시 제어"없이 응답 헤더 을 어떻게 처리합니까 방법 :하지만 문제 여전히 미해결이다

Answer 1

기본 캐시 제어 헤더는 다음과 같습니다 개인

캐시 메커니즘은이 페이지를 개인용 캐시에 캐시하고 단일 클라이언트에만 재전송 할 수 있습니다. 이것이 기본값입니다. 대부분의 프록시 서버는이 설정으로 페이지를 캐시하지 않습니다.

브라우저가 자원에게이 새로운 (?) 페이지를로드 할 때마다 요청하는 캐시 제어 헤더없이 http://msdn.microsoft.com/en-us/library/ms524721%28v=vs.90%29.aspx

Answer 2

를 참조하십시오. F5를 누르면 해당 페이지 내의 캐시 된 항목이 무효화 (또는 논리적으로 제거)됩니다. 로컬 버전을 사용할 수 없으므로 전체 재로드를 강요합니다. 브라우저가 다시 요청하기 전에 캐시에서 해당 리소스를 제거하면 확실하지 않습니다.

재미있는 부분은 페이지로드 당 한 번만 리소스를 요청하는 것과 같은 일부 최적화가 필요한 일부 '추가 설정'이 있다는 것입니다. 카운터와 같은 모든 요청에 ​​대해 이미지가 변경되면 여러 번 사용하더라도이 이미지의 한 버전 만 표시됩니다.

다음은 브라우저가 명시 적으로 로컬 캐싱을 적용하여 nocache로 명시 적으로 설정되지 않은 이미지를 다시 사용한다는 것입니다. 다시 유효성을 검사하도록 설정하고 만료 됨을 -1로 설정해야 할 때마다 요청을 받으려는 경우.

따라서 리소스에 따라 사양을 읽는 것으로 예상되는 것과 다른 기본값을 트리거하지 않는 경우가 있습니다.

소스가 로컬, 드라이브 또는 실제 원거리 인터넷 서버로 표시되는지 여부에 따라 다른 동작이있을 수도 있습니다. 모든 브라우저가 다르게 작동하는 것은 아니며 제한적입니다.

www.google.com을 확인하고 페이지에서 요청하는 추적 픽셀 (metrics.gstats.com에서 요청한 1x1 픽셀 2 개, 하위 도메인에 임의의 부분 포함)을 찾으려면 무엇이 도움이되는지 알아보십시오.

Firebug를 사용하여 헤더를 체크 아웃하는 경우 가능한 모든 방법으로 nocache 지시문을 지정합니다. 헤더의 내용은 다음과 같습니다.

Alternate-Protocol 443:quic 
Cache-Control no-cache, must-revalidate 
Content-Length 35 
Content-Type image/gif 
Date Mon, 25 Nov 2013 14:33:30 GMT 
Expires Fri, 01 Jan 1990 00:00:00 GMT 
Last-Modified Tue, 14 Aug 2012 10:47:46 GMT 
Pragma no-cache 
Server sffe 
X-Content-Type-Options nosniff 
X-Firefox-Spdy 3 
X-XSS-Protection 1; mode=block 

설정으로 시도하여 브라우저가 변경된 리소스를 선택하지 못하는 문제를 해결하는지 확인하십시오.must-revalidate 지시어는 심지어 프록시 캐시가 매번 자원을 요청하고 304 Not Modified 응답을 확인하도록합니다.

나는 현재 비슷한 것을 경험합니다. 나는 로컬 호스트 연결을 etag 설정하고 그 모든 happends은 캐시가 묻지 않을 것입니다. 캐싱 정보 나 비슷하게 설정하지 않았습니다. FireFox가 리소스를 다시 요청하지 않도록하기 위해 etag 솔기를 지정합니다. 그래서 나는 당신의 문제와 비슷한 것을 경험합니다. 기본적으로 무엇을해야하는지 브라우저와 프록시

Answer 3

RFC 7234 세부 정보 : 캐싱은 HTTP의 완전히 선택적 기능이지만

이

, 그것은 이 될 수는 캐시 된 응답을 재사용하는 것이 바람직하다 그 같은 재사용이 있다고 가정 요구 사항이 없거나 로컬 구성을 사용할 수없는 경우의 기본 동작입니다. 따라서 HTTP 캐시 요구 사항은 이며, 캐시가 항상 특정 응답을 저장하고 재사용하도록 지시하는 대신 이 아닌 재사용이 불가능한 응답을 저장하지 못하도록하거나 저장된 응답을 부적절하게 재사용하는 데 중점을 둡니다.

Answer 4

캐싱은 일반적으로 브라우저에서 기본적으로 활성화되어 있으므로 cache-control을 사용하여이 동작을 사용자 지정하거나 사용하지 않도록 설정할 수 있습니다.

캐싱은 HTTP의 전적인 선택적인 기능이지만 캐싱 된 응답을 다시 사용하는 것이 바람직하고 요구 사항이나 로컬 구성으로 인해 캐싱이 방지되지 않는 경우 이러한 재사용이 기본 동작이라고 가정 할 수 있습니다. 따라서 HTTP 캐시 요구 사항은 캐시가 항상 특정 응답을 저장하고 재사용하도록 요구하는 것이 아니라 재사용이 불가능한 응답을 저장하거나 저장된 응답을 부적절하게 재사용하지 못하도록하는 데 중점을 둡니다.

원 서버가 항상 명시 적 만료 시간을 제공하지 않기 때문에, 캐시가 휴리스틱을 할당 할 수 있습니다 : [https://tools.ietf.org/html/rfc7234#section-2]

브라우저가 새로운 캐시 된 응답을 고려 시간은 보통이 마지막으로 수정 된 때를 기준으로합니다 (Last-Modified time과 같은) 다른 헤더 필드 값을 사용하는 알고리즘을 사용하는 명시적인 시간이 지정되지 않은 만료 시간 ... 응답에 Last-Modified 헤더 필드 ([RFC7232]의 2.2 절)가 있으면 캐시 그 시간 이후의 간격의 일부분을 넘지 않는 경험적 만료 값을 사용하는 것이 좋습니다. 이 분수의 일반적인 설정은 10 % 일 수 있습니다. [https://tools.ietf.org/html/rfc7234#section-4.2.2]

This post에는 다른 브라우저가 그 값을 계산하는 방법에 대한 세부 정보가 있습니다.

Answer 5

신선도 수명은 여러 헤더를 기반으로 계산됩니다. "Cache-control : max-age = N"헤더가 지정되면, 신선도 유효 기간은 N과 동일합니다.이 헤더가 존재하지 않는 경우 (매우 자주 발생합니다), Expires 헤더가 있는지 여부가 점검됩니다. Expires 헤더가 존재하면 그 값에서 Date 헤더의 값을 뺀 값은 신선도 수명을 결정합니다. 마지막으로 두 헤더가 모두 없으면 Last-Modified 헤더를 찾습니다. 이 헤더가 있으면 내가 캐시 제어를 볼 수 없습니다 이유를 다음 캐시의 신선한 기간은 날짜 헤더의 값을 뺀 10

https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Caching_FAQ