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

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이후 응답은 즉시 무효로 간주됩니다.

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

---

---

답변