"Vary : Accept"HTTP 헤더의 기능은 무엇입니까?

PHP를 사용하여 동적 웹 페이지를 생성합니다. 다음 자습서 (아래 링크 참조)에 설명 된대로 $ _SERVER [ 'HTTP_ACCEPT']에서 허용하는 경우 XHTML 문서의 MIME 유형은 "application / xhtml + xml"이어야합니다. 2 개의 다른 MIME ( "application / xhtml + xml"및 "text / html")로 동일한 페이지를 제공 할 수 있으므로 "Vary"HTTP 헤더를 "Accept"로 설정해야합니다. 이것은 프록시의 캐시에 도움이됩니다.

링크 : http://keystonewebsites.com/articles/mime_type.php

이제 다음의 의미를 잘 모르겠습니다 : header ( 'Vary : Accept'); 'Vary : Accept'가 정확히 무엇을할지 잘 모르겠습니다 ...

내가 찾은 유일한 설명은 다음과 같습니다.

Content-Type 헤더 다음에 Vary 헤더가 전송되어 프록시 서버와 같은 중간 캐시에 문서를 요청하는 클라이언트의 기능에 따라 문서의 콘텐츠 유형이 달라짐을 알립니다. http://www.456bereastreet.com/archive/200408/content_negotiation/

누구나이 헤더에 대한 "실제"설명을 제공 할 수 있습니다 ( 해당 값 포함 ). 나는 다음과 같은 것을 이해한다고 생각한다. Vary : Accept-Encoding 여기서 프록시의 캐시가 제공된 페이지의 인코딩을 기반으로 할 수 있지만 이해하지 못합니다. Vary : Accept

• 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의 동작과 관련이 있습니다.

Vary: Accept단순히 Accept요청 의 헤더를 기반으로 응답이 생성되었다고 말합니다 . Accept헤더가 다른 요청 은 다른 응답을받을 수 있습니다.

(링크 된 PHP 코드가를 보는 것을 볼 수 있습니다 $HTTP_ACCEPT. 이것이 Accept요청 헤더 의 값입니다 .)

HTTP 캐시의 경우 이는 응답을 특별히주의하여 캐시해야 함을 의미합니다. 정확히 동일한 Accept헤더를 가진 이후 요청에 대해서만 유효한 일치가됩니다 .

이제 이것은 페이지가 처음에 캐시 가능한 경우에만 중요합니다. 기본적으로 PHP 페이지는 그렇지 않습니다. PHP 페이지는 특정 헤더 ( Expires예 :)를 전송하여 출력을 캐시 가능한 것으로 표시 할 수 있습니다 . 그러나 그것을 수행하는지 여부와 방법은 다른 질문입니다.

이 Google 웹 마스터 동영상 에는 HTTP Vary헤더 에 대한 매우 좋은 설명이 있습니다.

실제로 Vary헤더를 매우 유용하게 만드는 많은 새로운 기능이 곧 출시 될 예정이며 이미 Chrome에 있습니다. 예를 들어 Client Hinting을 고려하십시오 . 예를 들어 이미지와 관련하여 사용되는 경우 클라이언트 힌팅을 사용하면 서버가 다음에 따라 이미지와 같은 리소스를 최적화 할 수 있습니다.

• 이미지 너비
• 뷰포트 폭
• 브라우저에서 지원하는 인코딩 유형 (WebP 생각)
• 다운 링크 (기본적으로 네트워크 속도)

따라서 이러한 기능을 지원하는 서버는이 Vary를 나타내는 헤더를 설정합니다 .

Chrome Vary은 각 요청 에 대한 헤더의 일부로 "image / webp"를 설정하여 WebP 지원을 알립니다 . 따라서 브라우저가 지원하는 경우 서버는 이미지를 WebP로 다시 작성할 수 있으므로 프록시는 WebP 이미지를 캐시하지 않도록 헤더를 확인한 다음 WebP를 지원하지 않는 브라우저에 제공해야합니다. 서버가 그렇게하지 않으면 문제가되지 않습니다. 따라서 서버의 응답은 Accept요청 헤더 에 따라 다르기 때문에 프록시를 혼동하지 않도록 응답에 포함해야합니다.

Vary: Accept

또 다른 예는 이미지 너비 일 수 있습니다. 모바일 브라우저에서 Width헤더는 데스크톱 브라우저에서 볼 때와 비교하여 반응 형 이미지의 경우 매우 작을 수 있습니다. 따라서이 경우 프록시가 소형 모바일 버전을 캐시하지 않고 데스크톱 브라우저에 제공하거나 그 반대 Width의 경우 Vary헤더에 추가해야합니다 . 이 경우 헤더에 다음이 포함될 수 있습니다.

Vary: Accept, Width

또는 서버가 모든 클라이언트 힌팅 사양을 지원하는 경우 헤더는 다음과 같습니다.

Vary: Accept, DPR, Width, Save-Data, Downlink