main_frame 요청을 캐싱 할 수 없습니다.

Question

http 응답 헤더를 수정하는 chrome 확장 기능을 연구 중입니다. https://chrome.google.com/webstore/detail/super-cache/fglobbnbihckpkodmeefhagijjcjnbeh/details

메인 프레임 요청을 캐시 할 수 없습니다. 정적 요청의 캐싱을 제어 할 수 있습니다.

예를 들어 http://apple.com을 누르면 main_frame에 대해 다음 헤더가 수신됩니다.

Accept-Ranges:bytes 
Cache-Control:max-age=276 
Connection:keep-alive 
Content-Encoding:gzip 
Content-Length:3310 
Content-Type:text/html; charset=UTF-8 
Date:Tue, 12 Mar 2013 09:24:12 GMT 
Expires:Tue, 12 Mar 2013 09:28:48 GMT 
Server:Apache 
Vary:Accept-Encoding 

하지만 내가 URL을 누를 때마다 브라우저는 서버에 액세스하려고 시도하고 궁극적으로 200 응답을 수신합니다. main_frame에서 캐싱을 사용하도록 헤더를 설정할 수있는 모든 가능한 조합을 시도했습니다.

사용자가 크롬의 탐색 바에서 URL을 누를 때 요청이 이루어지지 않으면 좋겠어요.

Answer 1

응답 헤더에 일종의 캐시 유효성 검사가 없습니다. ETag 헤더를 사용하여 고유 한 응답을 식별 할 수있는 값을 추가하여 헤더를 제어 할 수 있습니다. 당신은 Apache ETag documentation에 대해 조금 읽을 수 있지만 단순히 당신의 예제에 응답 헤더에 ETag: [filename]을 포함 할 것 :

Accept-Ranges:bytes 
Cache-Control:max-age=276 
Connection:keep-alive 
Content-Encoding:gzip 
Content-Length:3310 
Content-Type:text/html; charset=UTF-8 
Date:Tue, 12 Mar 2013 09:24:12 GMT 
Expires:Tue, 12 Mar 2013 09:28:48 GMT 
Server:Apache 
ETag: File:"somefile.html" 
Vary:Accept-Encoding 

이 ETag 값은 파일 이름, 파일 크기와 거의 아무것도 포함 할 수 있습니다, 사용자 정의 값, ... 세미콜론으로 분리 할 수 ​​있습니다 ;. 값에 공백이 있으면 큰 따옴표로 묶으십시오 ("). 예를 들어 :

는

ETag: File:"YouTube_cd_Fdly3rX8.jpg"; Size:12169 

가 함께 Cache-Control, Expires 및 (포함 브라우저가이를 해석하는 방법을 알고있는 경우)를 변경할 수있는 몇 가지 다른 헤더 값으로, 브라우저의 캐시 검증을위한 기초를 형성 할 것이다. 샘플 응답 헤더를 보면

는

, 당신은 훨씬 더 높은 값으로 Cache-Control, 당신의 예로서 그들은 단지 2백76초에 대한 클라이언트 측 캐시해야한다 제안 당신의 최대 사용 기간 값을 증가 할 수 있습니다. Expires 헤더 값도 조금 부족합니다.

이러한 값을 설정하는 방법과 브라우저가 캐시 제어 헤더의 유효성을 검사 할 것으로 예상되는 방법에 대한 추가 정보는 RFC2616, Section 14.9에서 읽을 수 있습니다.

편집 : 더 디버깅, 확인 및 크롬의 캐시 검증의 동작을 다시 확인해 본 결과, 밝혀이 실제로 제대로 존중 Cache-Control 응답 헤더를 설정하지 않습니다. 주 문서 요청에

크롬, 버전 25.0.1364.172 m

무시해 캐시 Control에서 정적 파일을 제공 : 영업의 요청에, 나는 크롬 지원이 문제를보고 한 링크 된 내용에 동일한 헤더 응답 을 존중하면서 웹 서버.

테스트 설정 : 웹 서버 (MIME 텍스트/HTML), IFRAME을 (또한 MIME 텍스트/HTML)를 withing에 또 다른 정적 HTML 문서를 포함 에서 정적 HTML 문서를 요청

.

이

Date: Thu, 21 Mar 2013 16:29:28 GMT 
Expires: Thu, 21 Mar 2013 16:33:59 GMT 
Cache-Control: max-age=301, max-stale=299, only-if-cached 

이 예상되는 동작 :

홈페이지 문서와 문서가 IFRAME 내에서 제공 캐시 할 것 IFRAME은 문서가 주 문서와 같은 웹 서버 응답하여 연결된 동일한 응답 헤더 을 가지고 봉사 로컬에서 최소 (max-age) 초 동안 초기 요청을하고, (비 강제)로드 요청의 경우 299 (최대 유효 기간) 초의 시간이 소요됩니다. 이 시간 내에있는 모든 후속 요청은 로컬 캐시를 무효화 할 것으로 예상되지 않으며 (CTRL + F5 또는 다시 불러 오기 상황에 맞는 메뉴 명령으로 강제 새로 고침) 정상적인 페이지로드 요청으로 시작됩니다 (예 : 주소 표시 줄에 관련 URL을 다시 입력하는 경우) 로컬 캐시 제어 정보 중 아무 것도 표시되지 않으면 상태 메시지 200 OK (캐시에서)와 함께 로컬 캐시에서로드됩니다 (동일한 URL, 은 유효한 캐시 시간 프레임에서 문서의 태그가 올바르게 응답 헤더에 캐시 된 ).

문제점 :

주 문서는 캐시 된 카피를 통해로드되지 않고 추가 수정 요청 상태 코드 304 없음 결과 웹 서버로 이루어진다. 그러나 IFRAME 내의 문서는 로컬 캐시에서 올바르게로드되고 상태 메시지 200 OK ( 캐시)가 생성됩니다.

참고 : 캐시 제어 태그 또는 그 값의 조합의

없음은 주 문서에 대한 로컬 캐시의 행동에 어떤 긍정적 인 영향을 미칠 을 보이지 않는다. 고유하지 않은 ETag 값을 포함하면 주 문서 캐싱 문제가 해결되지 않습니다. 다른 주요 공급 업체 브라우저 (IE, Firefox, Opera에서 테스트 됨)은 기본 문서의 캐시 제어 헤더를 존중합니다.