개요

Vary는 이 응답이 어떤 요청 헤더 값에 따라 달라지는지를 캐시에 알려주는 헤더입니다. 캐시는 동일 URL이라도 Vary에 나열된 헤더 값이 다르면 별개의 캐시 항목으로 취급해, 엉뚱한 사용자에게 잘못된 표현을 주는 일을 막습니다.

콘텐츠 협상(압축·언어·미디어 타입)이나 CORS를 쓰는 응답에서 캐시 정확성을 지키는 핵심 장치입니다.

자세히

예를 들어 서버가 Accept-Encoding에 따라 gzip 버전과 비압축 버전을 다르게 낸다면 Vary: Accept-Encoding이 없을 때 캐시가 gzip 응답을 gzip을 지원하지 않는 클라이언트에게 줘 깨진 콘텐츠를 보일 수 있습니다. 다국어 사이트에서 Accept-Language로 언어를 결정한다면 Vary: Accept-Language가 필요합니다.

CORS에서 서버가 Origin을 반사(reflect)해 Access-Control-Allow-Origin을 동적으로 낸다면 반드시 Vary: Origin을 함께 내야 합니다. 그렇지 않으면 공유 캐시가 A 오리진용 응답을 B 오리진에 재사용해 CORS가 깨지거나 캐시 오염(cache poisoning)이 생깁니다.

Vary: *는 응답이 URL 외의 명시되지 않은 요청 요인에 따라 달라져 사실상 캐시할 수 없음을 뜻합니다. 또한 Vary에 나열된 헤더 조합의 카디널리티가 높을수록(예: User-Agent) 캐시 파편화가 심해져 히트율이 급락하니 꼭 필요한 헤더만 나열해야 합니다.

문법

Vary: <header>[, <header>]* | *

e.g. Vary: Accept-Encoding, Accept-Language

지시어 / 값

실무 참고

• Vary: User-Agent는 UA 문자열이 사실상 무한히 다양해 캐시를 거의 무력화합니다. 기기별 응답이 필요하면 Client Hints 등 카디널리티가 낮은 신호를 고려하세요.
• 쿠키에 따라 응답이 달라지면 Vary: Cookie가 필요하지만, 이는 사용자마다 캐시가 갈려 공유 캐시 효율이 사라집니다. 이런 응답은 Cache-Control: private로 두는 편이 낫습니다.
• 누락된 Vary는 조용한 버그의 원천입니다. 압축·언어·오리진에 따라 응답이 달라지는데 Vary를 빠뜨리면 특정 사용자에게만 재현되는 이상한 캐시 문제가 생깁니다.

관련 헤더

관련 상태코드

스펙 근거