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

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.