2013-08-20 3 views
0

AWS에서 호스팅되는 js가 있습니다. 304 GET 요청에 대해 추가 비용을 지불하지 않도록 캐시하고 싶지만 두 헤더가 다른 이유는 의아해합니다.요청 헤더 캐시 정책과 응답 헤더의 차이점

Request Method:GET 
Status Code:304 Not Modified 

요청 helper.js

Accept:*/* 
Accept-Encoding:gzip,deflate,sdch 
Accept-Language:en-US,en;q=0.8 
Cache-Control:max-age=0 
Connection:keep-alive 
If-Modified-Since:Tue, 20 Aug 2013 13:08:13 GMT 

의 헤더와 응답 헤더가 다른 이유

Age:4348 
Cache-Control:max-age=604800 
Connection:keep-alive 

? 캐시 제어가 잘못되었다는 의미입니까? 헤더를 가져 오기 위해 Chrome 콘솔을 사용했습니다.

+0

나는 약간 혼란 스럽다. 클라이언트 측에서 Cache-Control 헤더를 보낸 경우에도 서버가 다른 Cache-Control 헤더로 응답 한 이유는 무엇입니까? 그 일이 일어날 것을 기대하고 계시 니? –

+0

기본적으로, 나는 내 js 캐시하려는 및 그 두 가지 다른 캐시 제어가 있다는 것을 의미합니까? –

답변

0

캐시 제어가 잘못되었다고 생각하지 않아 콘텐츠가 이미 캐시 된 것처럼 보입니다. 요청 헤더에서 브라우저가 서버를 "hey, 그 시간 이후로 변경 되었습니까?"라고 표시하므로 Tue, 20 Aug 2013 13:08:13 GMT에서 첫 번째 요청이 완료되었음을 이해합니다. 대신에 서버는 304 Not Modified 헤더로 응답하여 내용이 변경되지 않았 음을 나타내며 캐시를 재확인 할 때까지 더 많은 시간을 캐시해야합니다(). 캐싱은 서버 측에서 수행됩니다. 따라서 js 파일에 대한 서버 정의를 살펴볼 수 있습니다. 일반적으로 배포 환경에서 웹 서버에 * .js * .png 등의 캐시 헤더를 보내도록 지시합니다. 캐시 헤더를 전송하도록 웹 서버를 구성한 후에는 나머지를 처리하는 것이 브라우저의 작업입니다. 이 경우 브라우저가 예상대로 작동합니다.

RFC2616에서 304 응답을 볼 수 있습니다. this decent caching tutorial을보고 싶을 수도 있습니다. 그것은 몇 가지 아이디어를 분명히해야합니다.

0

Chrome에 문제가 있습니다. 새로 고침 버튼을 누르면 캐시를 무효화하지만 주소 표시 줄에서 Enter를 누르면 캐시에서 자원을 가져옵니다.