HTTP 프로토콜 Vary 헤더

• HTTP 헤더 중에는 Vary 헤더가 있음

• Vary 헤더는 동일한 URL에 대해 요청을 하더라도 요청한 사용자의 특징(User Agent, Accept Encoding, Origin 등등)에 따라 서로 다른 응답을 해 주기 위해서 존재함

• 웹 캐시에서는 Vary 헤더를 확인하고 해당 헤더에서 명시하는 조건에 따라 동일 URL이라 하더라도 다른 종류의 컨텐츠를 캐싱하고, 제공함

• Vary 헤더는 200 OK 응답과 동일하게 304 Not Modified 응답에서도 설정되어야함

• Vary 헤더를 사용하는 경우, 서버는 캐쉬한 응답을 적절한 Accept-Encoding 요청 헤더를 보낸 클라이언트에게만 보내도록 Vary: Accept-Encoding으로 설정

  
  

• 하나의 웹컨텐츠를 데스크톱과 모바일에서 서로 다르게 보여줘야 할 경우가 있음 → URI 정보로는 동일한 컨텐츠

  1. 웹서버에서는 프로그램으로 잘 표현되나, 캐시서버가 컨텐츠를 캐싱하고 있는 경우 문제가 발생 가능
  2. 모바일에서 컨텐츠를 요청하였을 때, 캐시서버가 데스크톱 컨텐츠를 직접 전달하여 문제가 발생할 수 있음
  3. 반대로 데스크톱 컨텐츠를 요청하였을 때, 캐시서버가 모바일 컨텐츠를 직접 전달하여 문제가 발생할 수도 있음
  4. Vary 헤더의 값으로는 HTTP 요청 헤더명이 사용
  5. 예시로 User-Agent를 값으로 사용

     Vary: User-Agent

     
     

• 캐싱하고 있는 컨텐츠의 최초 User-Agent 정보가 일치하지 않으면 캐싱된 컨텐츠를 전달 X

• 최초 모바일로 트와이스 이미지를 요청하여 전달받게 되면 캐싱된 트와이스 이미지는 모바일 User-Agent 값인 경우에만 직접 전달 가능 ->데스크톱에서는 캐싱된 트와이스 이미지를 사용 불가
  
  
  

Vary 헤더를 사용한 캐시와 웹 서버의 동작

1. 모바일 사용자가 twice.jpg 이미지를 요청 (최초의 요청)
2. 최초 요청이기 때문에 캐시 서버는 웹서버에게 클라이언트의 요청을 그대로 전달
3. 웹 서버에게 클라이언트의 요청 이미지를 전달 받음(응답에 Vary: User-Agent 헤더 포함)
4. 전달받은 이미지는 캐시 서버의 저장공간에 저장한 후 모바일 사용자에게 전달
5. 동일한 이미지를 모바일 사용자가 아닌 데스크톱 사용자가 요청
6. 분명 동일한 URI 경로에 요청임에도 불구하고 캐싱된 이미지를 전달 X(이전 캐싱된 컨텐츠와 요청한 컨텐츠의 User-Agent가 다름) → 웹 서버에게 클라이언트의 요청을 그대로 전달
7. 웹서버가 캐시 서버에게 동일하지만 Vary 헤더가 다른 컨텐츠를 전달
8. 그렇기에 프록시 서버는 동일한 URI 요청임에도 불구하고 캐싱할 당시의 User-Agent 정보를 비교하고 내용이 다르기에 캐싱된 컨텐츠를 직접 전달 X → 응답 헤더의 Vary : User-Agent가 다른 경우 caching된 컨텐츠 전달 X
   

   

HTTP의 Vary 헤더의 문법

Vary: *
Vary: <header-name>, <header-name>, ...

HTTP Vary 헤더의 지시자

1. * (asterisk)

• 각 요청에 대해서 캐시할 수 없는 요청으로 간주
• 더 좋은 방법으로 Cache-Control: no-store를 사용 → 객체를 저장하면 안된다는 의미로 좀 더 명확하게 표시

2. <header-name>

• 헤더 이름은 쉼표로 구분되며 캐시된 응답을 사용할 수 있는지 여부를 결정할 때 사용