[http] “Vary : Accept”HTTP 헤더의 기능은 무엇입니까?

• cache-control헤더는 캐싱 프록시 응답의 “신선함”을 말할 수있는 HTTP 서버에 대한 기본 메커니즘입니다. (즉, 캐시에 응답을 저장하는 방법 / 기간)

• 어떤 상황에서는 cache-control지시문이 충분하지 않습니다. HTTP 작업 그룹의 토론이 여기에 보관 되어 언어로만 변경되는 페이지를 설명합니다. 이다 하지 (가) 헤더 변화에 대한 올바른 사용 사례,하지만 상황은 우리의 논의 가치가있다. (이 경우 Vary 헤더가 문제를 해결할 것이라고 생각하지만 더 나은 방법이 있습니다.) 해당 페이지에서 :

Vary 프록시가 서버가 수행 할 작업을 복제하는 것이 절망적이거나 지나치게 복잡한 경우에만 해당됩니다.

• RFC2616 “Header-Field Definitions” 는 서버 관점에서 헤더 사용을 설명하고 , 캐싱 프록시 관점에서 RFC2616 “Caching Negotiated Responses” 를 설명합니다. 요청의 고유성을 결정하는 HTTP 요청 헤더 집합을 지정하기위한 것입니다.

인위적인 예 :

HTTP 서버에 큰 랜딩 페이지가 있습니다. 사용자가 이전에 있었는지 여부에 따라 동일한 URL을 가진 약간 다른 두 페이지가 있습니다. 귀하는 쿠키를 기반으로 요청과 사용자의 “방문수”를 구분합니다. 그러나-서버의 랜딩 페이지가 너무 크기 때문에 가능한 경우 중개 프록시가 응답을 캐시하기를 원합니다.

URL, Last-Modified 및 Cache-Control 헤더는 캐싱 프록시에이 정보를 제공하기에 충분하지 않지만을 추가 Vary: Cookie하면 캐시 엔진이 캐시 결정에 Cookie 헤더를 추가합니다.

마지막으로 트래픽이 적은 동적 웹 사이트의 경우 항상 간단 Cache-Control: no-cache, no-store하고 Pragma: no-cache충분합니다.

편집-질문에보다 정확하게 대답하기 위해 : HTTP 요청 헤더 ‘Accept’는 클라이언트가 처리 할 수있는 콘텐츠 유형을 정의합니다. 동일한 URL에 Content-Type 만 다른 동일한 콘텐츠의 사본이 두 개있는 경우 사용하는 Vary: Accept것이 적절할 수 있습니다.

업데이트 11 Sep 12 :

이 댓글이 처음 게시 된 이후 댓글에 표시된 몇 개의 링크를 포함하고 있습니다. 둘 다 Vary : Accept의 실제 사례 (및 문제)를위한 훌륭한 리소스입니다. 이 답변을 읽고 있다면 해당 링크도 읽어야합니다.

첫 번째는 뛰어난 EricLaw에서 Vary 헤더를 사용한 Internet Explorer의 동작과 개발자에게 제시하는 몇 가지 과제에 대한 것입니다. Vary Header Prevents Caching in IE . 간단히 말해 IE (IE9 이전)는 요청 캐시에 HTTP 요청 헤더가 포함되어 있지 않기 때문에 Vary 헤더를 사용하는 콘텐츠를 캐시하지 않습니다. EricLaw (실제 세계의 Eric Lawrence)는 IE 팀의 프로그램 관리자입니다.

두 번째는 Eran Medan의 것이며 Chrome의 Vary 관련 예기치 않은 동작에 대한 지속적인 논의입니다. Backing은 Vary 헤더를 올바르게 처리하지 않습니다 . Chrome 개발자가 다른 접근 방식을 취했다는 점을 제외하면 IE의 동작과 관련이 있습니다.