Cache-Control 속성이 요청 헤더 (클라이언트에서 서버로)로 전송되는 이유는 무엇입니까?

Cache-Control 속성이 요청 헤더 (클라이언트에서 서버로)로 전송되는 이유는 무엇입니까?

---

Cache-ControlHTTP 헤더 의 필드에 대해 읽은 후

나는 이해 Cache-ControlHTTP 응답 헤더 (클라이언트 서버) 필드가 다른 값을 전송하여 응답을 처리하는 방법에 대한 중간 프록시 서버 / 클라이언트 브라우저에 대한 지침을 지정 Cache-Control필드 : private, public, no-cache, 또는 no-store응답 헤더입니다.

그러나 왜 Cache-Control요청 헤더 (클라이언트에서 서버로)로 속성 을 보내야 합니까?

---

Cache-Control: no-cache일반적으로 요청 프록시 (웹 브라우저에서 서버로 전송)에 사용되어 중간 프록시의 리소스를 강제로 검증합니다. 클라이언트가이 요청을 서버에 보내지 않으면 중간 프록시는 내용이 최신 인 경우 ( Expire또는 max-age필드 에 따라 만료되지 않은 경우) 컨텐츠의 사본을 리턴합니다 . Cache-Control이 프록시가 사본이 신선하더라도 사본을 다시 확인하도록 지시합니다.

---

클라이언트는 Cache-Control요청 경로를 따라 원본 서버 및 모든 중간 프록시 서버에서 유효성 다시 확인과 같은 특정 캐싱 동작을 요청하기 위해 요청에 헤더를 보낼 수 있습니다 .

---

위의 답변 외에도
캐시 체인이 구현되는 설정이있을 수 있습니다. 이 경우 요청이 충족되지 않은 첫 번째 캐시에 도달하면 추가 체인 캐시로 갈 수 있습니다.

따라서 서버에서 항상 응답을 받으려면 요청 헤더에 캐시 제어를 포함시킵니다. 이렇게하면 항상 서버에서 응답을받을 수 있습니다.

참고 URL : https://stackoverflow.com/questions/14541077/why-is-cache-control-attribute-sent-in-request-header-client-to-server