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

"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헤더를 가진 이후 요청에 대해서만 유효한 일치가됩니다 .

Now this only matters if the page is cacheable in the first place. By default, PHP pages aren't. A PHP page can mark the output as cacheable by sending certain headers (Expires, for example). But whether and how to do that is a different question.

---

There are actually a significant number of new features coming soon (and already in Chrome) that make the Vary header extremely useful. For example, consider Client Hinting. When used in connection with images, for example, client hinting allows a server to optimize resources such as images depending on:

• Image Width
• Viewport Width
• Type of encoding supported by browser (think WebP)
• Downlink (essentially network speed)

So a server which supports those features would set the Vary header to indicate that.

Chrome advertises WebP support by setting "image/webp" as part of the Vary header for each request. So a server might rewrite an image as WebP if the browser supports it, so the proxy would need to check the header so as to not cache a WebP image and then serve it to a browser that doesn't support WebP. Obviously, if your server doesn't do that, it wouldn't matter. So since the server's response varies on the Accept request header, the response must include that so as not to confuse proxies:

Vary: Accept

Another example might be image width. On a mobile browser the Width header might be quite small for a responsive image, in comparison with what it would be if viewed from a desktop browser. So in that case Width would be added to the the Vary header is essential for proxy to not cache the small mobile version and serve it to desktop browsers, or vice versa. In that case, the header might include:

Vary: Accept, Width

Or in the case that a server supported all of the client hinting specs, the header would be something like:

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

---

This google webmaster video has a very good explanation about HTTP Vary header.

참고URL : https://stackoverflow.com/questions/1975416/what-is-the-function-of-the-vary-accept-http-header