캐시 없음과 재확인의 차이점

캐시 없음과 재확인의 차이점

---

RFC 2616에서

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1

캐시하지 않음

no-cache 지시문이 field-name을 지정하지 않으면, 캐시는 오리진 서버와의 재확인없이 후속 요청을 만족시키기 위해 응답을 사용해서는 안됩니다. 이를 통해 오리진 서버는 클라이언트 요청에 부실 응답을 리턴하도록 구성된 캐시로도 캐싱을 방지 할 수 있습니다.

따라서 상담원이 모든 응답 을 다시 확인하도록 지시합니다 .

이것을 다음과 비교

재확인

캐시가 수신 한 응답에 must-revalidate 지시문이있는 경우, 해당 캐시는 원래 서버로 먼저 재확인하지 않고 후속 요청에 응답하기 위해 부실한 항목을 사용해서는 안됩니다.

따라서 에이전트가 부실 응답 을 다시 확인하도록 지시합니다 .

특히 no-cache, 이것이 사용자 에이전트가 실제로이 지시문을 경험적으로 처리하는 방법입니까?

의 핵심 기능 no-cache이 있는지 must-revalidate와는 max-age?

이 의견을보십시오 :

http://palpapers.plynt.com/issues/2008Jul/cache-control-attributes/

캐시하지 않음

이 지시문은 브라우저가 페이지를 캐시하지 않도록 지시하는 것처럼 들리지만 미묘한 차이가 있습니다. RFC에 따르면 "no-cache"지시문은 캐시에서 페이지를 제공하기 전에 서버에서 서버를 다시 활성화해야한다는 것을 브라우저에 지시합니다. 재확인은 애플리케이션이 대역폭을 절약 할 수있는 깔끔한 기술입니다. 브라우저가 캐시 한 페이지가 변경되지 않은 경우 서버는 브라우저에이를 알리기 만하면 페이지가 캐시에서 표시됩니다. 따라서 브라우저 (이론상 이론적으로)는 페이지를 캐시에 저장하지만 서버와 다시 유효성 검사 한 후에 만 ​​페이지를 표시합니다. 실제로 IE와 Firefox는 no-cache 지시문을 브라우저가 페이지를 캐시하지 않도록 지시하는 것처럼 처리하기 시작했습니다. 우리는 약 1 년 전에이 행동을 관찰하기 시작했습니다.

누구든지 이것에 대해 더 공식적인 것을 얻었습니까?

최신 정보

must-revalidate 지시문은 표현에 대한 요청의 유효성을 검증하지 못하면 자동으로 실행되지 않는 금융 거래와 같은 올바르지 않은 조작이 발생할 수있는 경우에만 서버에서 사용해야합니다.

그것은 지금까지 결코 생각하지 못한 것입니다. RFC는 가볍게 검토해야한다는 말을하고 있습니다. 문제는 웹 서비스를 사용하면 부정적인 견해를 갖고 알 수없는 클라이언트 앱에 대해 최악의 상황을 가정해야합니다. 오래된 리소스는 문제를 일으킬 가능성이 있습니다.

그리고 Last-Modified 또는 ETags없이 방금 고려한 사항은 브라우저가 전체 리소스를 다시 가져올 수만 있습니다. 그러나 ETag를 사용하면 Chrome이 적어도 모든 요청에 ​​대해 다시 확인되는 것으로 나타났습니다. 요청에 어쨌든 '항상 재확인'을 유발하는 다른 헤더가 포함되어 있지 않으면 이러한 지시문이 모두 불명확하거나 적어도 이름이 잘못 지정되어 제대로 재확인 할 수 없기 때문입니다.

마지막 요점을 더 명확하게하고 싶습니다. must-revalidateETag 또는 Last-Modified를 설정 하지 않고 설정 만하면 에이전트는 비교할 서버로 보낼 내용이 없으므로 컨텐츠를 다시 가져올 수 있습니다.

그러나 경험적 테스트에 따르면 ETag 또는 수정 된 헤더 데이터가 응답에 포함되면 에이전트는 must-revalidate헤더 의 존재 여부에 관계없이 항상 다시 확인 됩니다.

의 요점은 그래서 must-revalidate당신이 평생 / 연령을 설정 한 경우 경우에만 따라서 일어날 수있는 오래된가는 때 '바이 패스 캐시'를 강제하는 것입니다 must-revalidate없음 나이 또는 다른 헤더와 응답에 설정되어, 효과적으로에 해당되고 no-cache이후 응답은 즉시 무효로 간주됩니다.

-마지막으로 길리의 답변을 표시하겠습니다!

---

must-revalidate"캐시가 만료되면 부실 응답이 허용된다고 말하더라도 부실 응답을 사용자에게 반환하지 않습니다" 를 의미합니다. 반면이 no-cache의미 must-revalidate를 더한 사실은 응답이 부실 바로이된다.

응답을 10 초 동안 캐시 할 수 있으면 10 초 후에 must-revalidate시작되고 0 초 후에는 no-cache암시 must-revalidate됩니다.

적어도 그것은 내 해석입니다.

---

max-age=0, must-revalidate와 no-cache정확하게 동일하지 않다. 로 must-revalidate서버가 유효성 재확인 요청에 응답하지 않으면 브라우저 / 프록시는 504 오류를 반환합니다. 을 사용하면 no-cache캐시 된 콘텐츠 만 표시되며 사용자가 선호하는 것일 수 있습니다 (아무것도없는 것보다 낫습니다). 이것이 must-revalidate중요한 거래만을위한 이유 입니다.

---

약 제프리 폭스의 해석과 함께 no-cache, 내가 크롬 52.0.2743.116 m에서 시험 한 결과 쇼 no-cache와 같은 행동이 must-revalidate그들 모두는 것, NOT 서버에 연결할 때 로컬 캐시를 사용하고, 그들은 모두 탭 브라우저의 뒤로 동안 캐시를 사용을 서버에 연결할 수없는 경우 / Forward 단추. 위와 같이, 적어도 구현에서는 max-age=0, must-revalidate동일 하다고 생각 no-cache합니다.

---

max-age=0, must-revalidate와 사이에 차이점이 있다고 생각합니다 no-cache.

이 must-revalidate경우 클라이언트는 If-Modified-Since요청 을 보내고 캐시에서 응답을 제공 할 수 304 Not Modified있습니다.

이 no-cache경우 클라이언트는 응답을 캐시하지 않아야하므로 사용하지 않아야합니다 If-Modified-Since.

참고 URL : https://stackoverflow.com/questions/18148884/difference-between-no-cache-and-must-revalidate