Vary

Vary 는 같은 주소의 응답이라도 요청에 따라 달라질 수 있다고 캐시에게 알리는 응답 헤더입니다. 서버는 응답을 고를 때 참고했을 수 있는 요청 헤더의 이름을 여기에 적습니다. 캐시는 그 헤더의 값까지 맞는 요청에만 저장해 둔 응답을 바로 내줍니다.

상세

Vary 는 HTTP(HyperText Transfer Protocol) 응답에 실리는 헤더입니다. 요청 메서드와 대상 URI(Uniform Resource Identifier, 자원을 가리키는 주소) 말고, 요청의 어느 부분이 이 응답의 내용을 고르는 데 영향을 줬을 수 있는지를 적습니다. 서버가 요청의 Accept-Language 를 보고 응답 언어를 골랐다면 Vary: Accept-Language 를 붙이는 식입니다.

Accept-Language 는 사용자가 원하는 언어를 서버에 알리는 요청 헤더입니다. Vary 는 대개 이렇게 요청이 선호를 밝히고 서버가 그걸 보고 응답을 고른 경우에 붙습니다.

콘텐츠 협상

서버는 같은 정보를 여러 형태로 낼 수 있습니다. 형식이 다르거나 언어가 다르거나 인코딩이 다른 형태입니다. 이 형태 하나하나를 표현(representation)이라고 부릅니다.

받는 쪽도 제각각입니다. 브라우저처럼 사용자를 대신해 요청을 보내는 프로그램이 사용자 에이전트입니다. 사용자 에이전트마다 능력과 선호가 달라서 어느 표현이 가장 알맞은지가 갈립니다. 그중 하나를 고르는 HTTP 의 장치가 콘텐츠 협상입니다.

요청이 선호를 실어 보내고 서버가 그걸 보고 고르는 방식에는 proactive negotiation 이라는 영어 이름이 붙어 있습니다. Vary 는 이 방식으로 고른 응답에 자주 붙습니다. 선택에 요청의 어느 부분이 쓰였는지를 알리려는 것입니다.

헤더 이름 목록과 별표

Vary 의 값은 쉼표로 이은 목록입니다. 목록의 원소는 요청 헤더 이름이거나 별표(*)입니다.

Vary: Accept-Language
Vary: Accept-Encoding, Accept-Language
Vary: *

목록에 적힌 헤더 이름은 원어로 selecting header fields 입니다. 응답을 고르는 데 한몫했을 수 있는 헤더라는 뜻입니다. 아래에서는 줄여서 「지목된 헤더」라고 부릅니다. 표준에 정의된 헤더만 지목할 수 있는 것은 아닙니다.

별표는 요청의 다른 부분이 응답 선택에 한몫했을 수 있다는 신호입니다. 메시지 문법 밖의 것도 들어갈 수 있습니다. 클라이언트의 네트워크 주소가 그 예입니다.

목록에 별표가 들어 있으면 헤더 이름이 함께 적혀 있어도 이 신호로 읽습니다. 그런 응답은 캐시에서 언제나 일치하지 않는 것으로 판정됩니다.

그래서 별표가 든 응답을 받은 쪽은 요청을 오리진 서버에 보내 보기 전에는 이 응답이 다음 요청에 맞는지 판단할 수 없습니다. 오리진 서버는 응답의 원본을 가진 서버입니다.

클라이언트와 서버 사이에서 요청을 대신 전달하는 프록시는 Vary 값에 별표를 만들면 안 됩니다(MUST NOT). 대문자 MUST NOT 은 반드시 지켜야 하는 금지입니다.

Vary 가 알리는 두 가지

지목된 헤더 목록은 받는 쪽 둘에게 각각 다른 것을 알립니다.

첫째는 캐시입니다. 캐시는 이 응답을 저장했다가 다음 요청에 답할 때, 지목된 헤더의 값이 처음 요청과 같아야만 이 응답을 쓸 수 있습니다. 처음 요청은 그 응답을 저장하게 만든 요청입니다. 값이 다르면 쓰면 안 됩니다(MUST NOT).

오리진 서버가 재사용을 확인해 준 경우만 예외입니다. 저장된 응답을 다시 써도 되는지 오리진 서버에 확인받는 일이 재검증입니다.

캐시가 저장된 응답을 찾을 때 쓰는 정보가 캐시 키입니다. 기본은 요청 메서드와 대상 URI 입니다. Vary 는 새 요청과 저장된 응답을 맞춰 볼 때 쓰는 이 캐시 키를 넓힙니다.

캐시 키가 넓어지면 같은 URI 아래 저장된 응답이 여럿으로 갈립니다. 캐시는 그 응답들을 처음 요청에 실렸던 헤더 값으로 가립니다. 아래 그림은 Vary: Accept-Language 가 붙은 응답 둘이 한 URI 아래 저장된 모습입니다.

flowchart TD
    K["기본 캐시 키 · 메서드와 대상 URI"]
    subgraph S["Vary: Accept-Language 로 넓힌 캐시 키"]
        R1["처음 요청의 Accept-Language 가 한국어 · 한국어 응답"]
        R2["처음 요청의 Accept-Language 가 영어 · 영어 응답"]
    end
    K --> R1
    K --> R2

새 요청이 오면 캐시는 그 요청의 Accept-Language 를 보고 둘 중 맞는 쪽만 꺼낼 수 있습니다. 저장된 응답 하나를 내줄 수 있는 요청도 그만큼 좁아집니다.

둘째는 사용자 에이전트입니다. 이 응답이 콘텐츠 협상을 거쳤다는 것을 알립니다. 지목된 헤더에 다른 값을 실어 다시 요청하면 다른 표현이 올 수 있다는 뜻입니다.

서버가 Vary 를 붙일 때와 뺄 때

오리진 서버는 캐시할 수 있는 응답을 아무 다음 요청에나 내주지 않고 맞는 요청에만 다시 쓰이게 하고 싶을 때 Vary 를 붙이는 것이 좋습니다(SHOULD). SHOULD 는 이유가 있으면 어길 수 있는 권고입니다. 대개 응답 내용을 지목된 헤더가 밝힌 선호에 맞춰 다듬었을 때가 그렇습니다. Accept-Language 를 보고 언어를 고른 응답이 그 예입니다.

반대로 빼도 되는 때가 있습니다. 오리진 서버가 내용 선택의 차이보다 Vary 가 캐시 성능에 주는 부담이 더 크다고 볼 때입니다. 응답의 재사용이 캐시 응답 지시어로 이미 제한돼 있으면 특히 그렇습니다.

캐시 응답 지시어는 응답의 Cache-Control 헤더에 적는 지시입니다. Cache-Control 은 캐시가 응답을 저장하고 다시 쓰는 방식을 지시하는 헤더입니다. 재사용이 이미 제한돼 있다는 것은 이 응답을 다른 요청에 내줄 수 있는 경우가 지시어 때문에 벌써 좁다는 뜻입니다.

Vary 가 아예 빠지면 캐시는 메서드와 대상 URI 만 보고 저장된 응답을 고릅니다. 언어로 응답을 고르는 서버라면 먼저 저장된 한국어 응답이 영어를 원하는 다음 요청에 나갈 수 있습니다. 아래 그림이 그 장면입니다.

sequenceDiagram
    participant U1 as 사용자 에이전트 1
    participant U2 as 사용자 에이전트 2
    participant C as 캐시
    participant O as 오리진 서버
    U1->>C: 요청 · Accept-Language 한국어
    C->>O: 저장된 응답이 없어 넘긴다
    O-->>C: 한국어 응답 · Vary 없음
    C-->>U1: 한국어 응답 · 캐시에 저장한다
    U2->>C: 요청 · Accept-Language 영어
    Note over C: 메서드와 대상 URI 만 맞춰 본다
    C-->>U2: 저장된 한국어 응답
    Note over C,O: Vary: Accept-Language 가 있었다면 여기서 대개 오리진 서버로 보낸다

선호를 밝히지 않은 요청에 나가는 응답을 기본 응답이라고 합니다. 어떤 자원은 이 기본 응답에 실수로 Vary 를 빠뜨립니다. 그러면 더 알맞은 응답이 저장돼 있어도 그 기본 응답이 다음 요청에 골라지는 일이 생깁니다.

출처 문서

Vary 의 정본은 RFC(Request for Comments) 두 편입니다. RFC 는 IETF(Internet Engineering Task Force, 국제 인터넷 표준화 기구)가 내는 기술 문서의 연번입니다. 필드의 뜻과 값은 RFC 9110 의 §12.5.5 가 정합니다. 캐시가 Vary 로 저장된 응답을 맞춰 보는 규칙은 RFC 9111 의 §4.1 이 정합니다.

두 문서 모두 Standards Track 범주입니다. 표준이 되는 절차를 밟는 문서 범주라는 뜻입니다.

RFC 9110 §15.4.5 는 304 Not Modified 응답에도 Vary 를 요구합니다. 304 는 조건을 단 GET·HEAD 요청에 보내는 응답입니다. 그 조건이 아니었다면 200 (OK) 으로 답했을 요청입니다. 같은 요청에 200 으로 답했다면 Vary 를 보냈을 경우, 304 를 만드는 서버는 Vary 도 만들어야 합니다(MUST).

옛 판

Vary 는 전에 RFC 7231 §7.1.4 와 RFC 7234 §4.1 에 있었습니다. RFC 7231 은 2014년 6월에 나왔습니다. 지금은 RFC 9110 이 그 문서를 폐기했습니다. RFC 7234 는 RFC 9111 이 폐기했습니다. 옛 절 번호를 인용하면 폐기된 판을 드는 것입니다.

RFC 7231 의 SHOULD 에는 단서가 둘 붙어 있었습니다. 첫째는 그 차이를 넘나들 수 없을 때(the variance cannot be crossed)입니다. 무엇을 넘나든다는 것인지는 원문이 더 풀지 않습니다(미확인).

둘째는 오리진 서버가 캐시 투명성을 일부러 막도록 설정됐을 때입니다. 캐시 투명성은 캐시가 끼어도 클라이언트가 받는 응답이 오리진 서버에서 직접 받은 것과 달라지지 않는 성질입니다. RFC 9110 의 SHOULD 문장에는 이 단서 둘이 없습니다.

RFC 9110 은 RFC 7231 에서 바뀐 점을 부록 B.3 에 적습니다. Vary 에 대해서는 다른 값과 함께 있는 별표의 뜻을 명확히 했다고 적습니다. 그 뜻은 상세의 「헤더 이름 목록과 별표」에 적은 대로입니다. 캐시 쪽 절의 제목도 RFC 7234 의 Calculating Secondary Keys with Vary 에서 지금의 이름으로 바뀌었습니다.

요구 수준

대문자 MUST 는 반드시 지킬 요구입니다. SHOULD 는 이유가 있으면 어길 수 있는 권고입니다. MAY 는 해도 되고 안 해도 되는 선택입니다.

구현에 맡긴 대목

캐시는 두 요청의 지목된 헤더를 견주기 전에 값을 다듬을 수 있습니다. 뜻이 같은 값을 같은 모양으로 맞추는 이 일이 정규화입니다. 순서가 무의미한 값을 재배열하거나, 대소문자를 안 가리는 값의 대소문자를 맞추는 일이 그 예입니다.

RFC 9111 §4.1 은 정규화를 「일어날 수도 있는(might take place)」 것으로 적습니다. 허용하는 변환을 늘어놓기만 합니다. 캐시가 그중 어디까지 하는지는 MUST·SHOULD 같은 요구 수준 키워드로 정하지 않습니다. 그래서 정규화를 어디까지 하느냐에 따라 같은 두 요청을 캐시마다 다르게 판정할 여지가 있습니다.

맞는 저장 응답이 여럿일 때 고르는 방법도 일부는 캐시에 맡깁니다. 지목된 헤더에 선호 순위를 매기는 장치가 있으면 그것으로 골라도 된다(MAY)고만 적습니다. Accept 계열 헤더 값에 붙는 선호도 가중치인 qvalue 가 그런 장치입니다.

맞는 응답이 없을 때 오리진 서버로 보내는 것도 「대개(Typically)」로 적혀 있습니다. 그 요청에 조건을 붙일지도 「그럴 수 있다(potentially)」로만 적혀 있습니다. 여기서 조건은 캐시가 이미 저장해 둔 응답이 무엇인지 오리진 서버에 알리는 것입니다.

예시

인코딩과 언어를 함께 지목한 응답

Vary: accept-encoding, accept-language

이 응답을 고를 때 오리진 서버가 요청의 Accept-Encoding 과 Accept-Language 를 판단 기준으로 썼을 수 있다는 뜻입니다. Accept-Encoding 은 클라이언트가 받을 수 있는 압축 방식을 알리는 요청 헤더입니다. 두 헤더가 요청에 없었다는 사실도 기준이 됐을 수 있습니다.

그래서 캐시는 두 헤더의 값이 처음 요청과 같은 다음 요청에만 이 응답을 재검증 없이 내줍니다. 처음 요청에 Accept-Language 가 없었다면 다음 요청에도 없어야 맞습니다. 헤더 이름은 대소문자를 가리지 않아서 소문자로 적어도 같은 헤더를 가리킵니다.

nginx 의 gzip_vary

gzip_vary on;

nginx 의 gzip 모듈에 있는 설정 지시어입니다. 켜 두면 압축과 관련된 설정 지시어 셋(gzip · gzip_static · gunzip) 가운데 하나가 동작할 때 응답에 Vary: Accept-Encoding 을 넣습니다.

기본값이 off 라서 따로 켜지 않으면 이 헤더를 넣지 않습니다. 이 헤더가 붙은 응답은 앞 예와 같은 규칙을 받습니다. 캐시는 Accept-Encoding 값이 처음 요청과 같은 요청에만 그 응답을 재검증 없이 내줍니다.

동작

이 절은 캐시가 새 요청을 받았을 때, Vary 가 붙은 저장 응답을 그 요청에 내줄지 정하는 순서를 다룹니다. 지목된 헤더가 처음 요청과 전부 맞는 저장 응답만 재검증 없이 내줍니다. 맞는 것이 하나도 없으면 요청을 대개 오리진 서버로 보냅니다.

이 Vary 검사는 캐시가 저장된 응답을 다시 쓰기 전에 보는 조건 가운데 하나입니다. 대상 URI 가 맞는지, 메서드가 그 응답을 쓰도록 허용하는지도 함께 봅니다.

flowchart TD
    A["메서드와 대상 URI 로 저장된 응답을 찾는다"] --> B{"찾은 응답에 Vary 가 있나"}
    B -->|없다| U["Vary 검사를 통과한다"]
    B -->|있다| C{"값에 별표가 들어 있나"}
    C -->|있다| X["일치하지 않는다 · 재검증 없이는 못 쓴다"]
    C -->|없다| D{"지목된 헤더가 처음 요청과 전부 맞나"}
    D -->|맞다| U
    D -->|안 맞다| X

1. 후보를 찾습니다. 기본 캐시 키인 요청 메서드와 대상 URI 로 저장된 응답을 찾습니다. 흔히 쓰는 HTTP 캐시 다수는 GET 응답만 저장해서 URI 만 캐시 키로 씁니다
2. Vary 를 봅니다. 후보에 Vary 가 없으면 Vary 검사는 통과입니다. 있으면 다음 단계로 갑니다
3. 별표를 봅니다. 값에 별표가 든 저장 응답은 언제나 일치하지 않습니다
4. 값을 견줍니다. 지목된 헤더를 새 요청과 처음 요청에서 꺼냅니다. 아래 변환으로 한쪽을 다른 쪽으로 바꿀 수 있을 때, 그리고 그때만 두 요청이 맞습니다
5. 없는 헤더를 봅니다. 정규화를 거친 뒤에도 한쪽 요청에 그 헤더가 없으면, 다른 쪽에도 없을 때만 맞습니다

4번에서 허용되는 변환은 셋입니다.

맞는 응답이 여럿이거나 없을 때

이 소절은 Vary 검사를 통과한 저장 응답이 여럿이거나 하나도 없을 때 캐시가 무엇을 하는지 다룹니다. 여럿이면 하나를 고릅니다. 없으면 대개 오리진 서버로 보냅니다.

flowchart TD
    A{"맞는 저장 응답이 있나"}
    A -->|하나도 없다| N["대개 오리진 서버로 보낸다 · 조건을 붙일 수 있다"]
    A -->|여럿이다| B{"선호 순위를 매기는 장치가 있나"}
    B -->|있다| Q["그 장치로 골라도 된다 · MAY"]
    B -->|없거나 동률| D["Date 가 가장 최근인 응답을 고른다"]

맞는 저장 응답이 여럿이면 캐시가 하나를 골라야 합니다. 지목된 헤더에 선호 순위를 매기는 장치가 있으면 그것으로 골라도 됩니다(MAY). 앞에서 본 qvalue 가 그런 장치입니다.

그런 장치가 없거나 써 봐도 동률이면 가장 최근 응답을 고릅니다. 최근인지는 응답이 만들어진 시각을 담는 Date 헤더로 판단합니다.

캐시가 고르지 않고 오리진 서버 쪽에 물을 수도 있습니다. 요청에 Cache-Control: max-age=0 이나 Cache-Control: no-cache 를 붙여 넘기는 방법입니다. 두 지시어는 저장된 응답을 오리진 서버에 확인받지 않고는 쓰지 말라는 요청 지시어입니다. 어느 응답을 쓸지 가리려는 것입니다.

같은 URI 의 저장 응답 가운데 Vary 를 빠뜨린 것이 섞여 있으면, 캐시는 유효한 Vary 값이 있는 가장 최근 응답을 고르는 것이 좋습니다(SHOULD).

맞는 응답이 하나도 없으면 캐시는 이 요청을 저장된 응답으로 채울 수 없습니다. 대개 요청을 오리진 서버로 보냅니다. 이미 저장해 둔 응답이 무엇인지 알리는 조건을 그 요청에 붙일 수도 있습니다. 이렇게 조건을 단 요청이 조건부 요청입니다.

경계

응답을 Authorization 헤더 값에 따라 골랐다면 Vary 에 Authorization 도 적어야 할까요? 아닙니다.

Authorization 은 사용자 에이전트가 오리진 서버에 자기를 인증하려고 자격 증명을 싣는 요청 헤더입니다. 이 헤더의 정의가 그 응답을 다른 사용자에게 다시 쓰는 것을 이미 막습니다. 그래서 Vary 로 한 번 더 막을 필요가 없습니다.

막는 쪽은 공유 캐시입니다. 공유 캐시는 여러 사용자가 함께 쓰는 캐시입니다. 공유 캐시는 Authorization 이 실린 요청에 대해 저장한 응답을 다음 요청에 쓰면 안 됩니다(MUST NOT).

예외는 두 조건이 함께 설 때입니다. 응답의 Cache-Control 에 공유 캐시 저장을 허용하는 지시어가 있어야 합니다. 캐시도 그 지시어를 따라야 합니다. HTTP 캐싱 표준에 정의된 응답 지시어 가운데서는 must-revalidate · public · s-maxage 셋이 그런 지시어입니다.

네트워크 지역도 Vary 에 적지 않아도 되는 경우가 있습니다. 이유는 Authorization 과 다릅니다. 다른 규칙이 막아 주는 것이 아니라 오리진 서버가 재사용을 원하는 경우입니다. 응답을 지역에 따라 골랐더라도, 사용자가 지역을 옮겨도 저장된 응답이 다시 쓰이길 오리진 서버가 원하면 그 차이를 Vary 에 적을 필요가 없습니다. 응답에 영향을 준 요청 부분이라고 전부 Vary 에 적어야 하는 것은 아닙니다.

관련 항목

Vary 를 정의하는 표준·문서

RFC 9110 · RFC 9111 · RFC 7231 · RFC 7234 · RFC 2119

Vary 가 지목하는 콘텐츠 협상 요청 헤더

Accept · Accept-Language · Accept-Encoding · Accept-Charset

304 응답이 Vary 와 함께 실어야 하는 헤더

Date · ETag · Content-Location · Cache-Control · Expires

Vary 가 선택 결과를 알리는 콘텐츠 협상 장치

콘텐츠 협상 · 표현 · qvalue · 사용자 에이전트

Vary 가 관여하는 캐시 개념

캐시 키 · 재검증 · 신선도 · 조건부 요청 · 304 Not Modified

Vary 를 읽고 저장 응답을 고르는 캐시

HTTP 캐시 · 브라우저 캐시 · 공유 캐시 · CDN · 리버스 프록시 캐시 · 프록시

Vary 를 응답에 붙이는 서버와 압축 기술

nginx · gzip · HTTP 압축 · Content-Encoding · Apache HTTP Server

Vary 에 안 적어도 되는 인증 헤더와 그 규칙

Authorization · HTTP 인증 · 자격 증명 · HTTP 401

Vary 가 속하는 상위 분류

HTTP · 헤더 · 필드 · 캐싱 · 오리진 서버