HTTP 헤더(2) - 일반 헤더 필드

 

 

* 해당 게시글은 <그림으로 배우는 Http&Network Basic>을 읽고 정리하면서 공부하기 위해 메모하듯 작성하는 글입니다.

 

 

---

 

 

Cache-Control

디렉티브로 불리는 명령을 사용해 캐싱 동작을 지정

• 지정한 디렉티브에 파라미터가 있을 수도 있고, 여러 디렉티브를 사용할 수도 있음

디렉티브 종류

public, private, no-cache 디렉티브는 캐시의 저장 여부를 결정하는 역할

public

Cache-Control: public

• 다른 유저에게도 돌려줄 수 있는 캐시를 해도 좋다고 명시

private

Cache-Control: private

• public 디렉티브와 기능이 정반대로 동작
• 특정 유저를 위해 리소스를 캐시하며, 다른 유저에게는 해당 캐시를 반환하지 않도록 함

no-cache

• 캐시로부터 오래된 리소스가 반환되는 것을 막기 위해 사용
• 클라이언트의 리퀘스트에서 사용한 경우: 캐시된 리스폰스를 안 받는단 의미→캐시가 유효한지 항상 오리진 서버에 확인
• 서버의 리스폰스에서 사용한 경우
  • 캐시 서버가 리소스를 저장하지 못하게 함
  • 이전에 저장한 캐시의 경우 리소스의 유효성 재확인하도록 함

Cache-Control: no-cache=Location

• • 위의 예시처럼 서버의 리스폰스에서만 no-cache의 필드 값에 헤더 필드 명을 지정할 수 있음→이 지정된 헤더 필드만 캐시할 수 없게 함

no-store

• 리퀘스트와 리스폰스에 기밀 정보가 포함됨을 암시→메시지의 일부분을 로컬 저장소에 저장하지 못하도록 함

후술할 s-maxage, max-age, min-fresh, max-stale 디렉티브는 캐시의 기한이나 검증을 지정하는 역할

max-age

Cache-Control: max-age=604800 (단위: 초)

• 클라이언트가 사용한 경우: 지정된 값보다 새로운 경우, 캐시된 리소스를 받겠다고 서버에 전달
  • age를 캐싱 후 경과 시간(나이)라고 하면, max-age는 캐시된 리소스의 나이가 지정한 값을 넘지 않아야 캐시된 리소스를 받는다고도 이해 가능
  • 지정한 값이 0이면 캐시 서버는 리퀘스트를 항상 오리진 서버로 전달해 원본을 응답받음
• 서버가 사용한 경우: 캐시 서버가 유효성 재확인 하지 않고 리소스를 보존하는 최대 시간을 정의
  • HTTP/1.1 캐시 서버: Expires 헤더 필드와 동시 적용한 경우→Expires 헤더 필드가 무시됨
  • HTTP/1.0: 반대로 max-age 디렉티브가 무시됨
• max-age 디렉티브를 적절히 설정하면 캐시된 리소스의 신선도를 유지하면서 오리진 서버로의 통신량 절약 가능

<max-age 디렉티브가 설정된 경우 요청 과정>

클라이언트가 서버에 요청
→서버 응답시 Last-Modified 헤더 필드를 통해 리소스 수정 날짜 정보 전달
→캐시로 저장시 해당 정보까지 저장
→클라이언트 재요청시 If-Modified-Since 헤더로 지정한 시간(Last-Modified 리스폰스 헤더 필드로 전달된 값을 지정) 이후로 수정된 적 있는지 서버에 질문
→수정된 적 있으면 리소스 전송(200 OK), 없으면 없다고 대답만(304 Not Modified) 전송-리소스를 전송하지 않아 통신량 절약

s-maxage

• max-age 디렉티브와 동일한 기능
• 차이
  • 공유 캐시 서버에만 적용
  • max-age 디렉티브보다 우선순위가 높음
  • 이 디렉티브를 사용하면 암시적으로 proxy-revalidate 디렉티브도 사용

min-fresh

Cache-Control: min-fresh=60 (단위: 초)

• 클라이언트 요청시: 캐시된 리소스가 적어도 지정된 시간은 최신 상태의 것을 반환하도록 서버에 요구
• 60초로 지정된 경우 60초 이내에 유효 기한이 끝나는 리소스를 리스폰스로 반환하면 안됨→60초 이상의 유효기간이 남은 캐시를 반환해야 함
  • max-age 디렉티브는 만들어지고 난 후 흘러간 시간을 의미하고, min-fresh 디렉티브는 유효기간이 끝날 때까지 남은 시간을 의미

max-stale

Cache-Control: max-stale=60 (단위: 초)

• 캐시의 유효 기간이 지났더라도, 디렉티브에 지정된 시간 이전까지는 받아들인다고 서버에 전달
• 값이 지정되지 않은 경우→아무리 유효시간이 경과했더라도 캐싱된 리스폰스를 받아들임

only-if-cached

Cache-Control: only-if-cached

• 클라이언트 요청: 캐시 서버에 캐싱된 경우에만 리스폰스를 반환해달라고 요구
  • 캐시 서버에서 리스폰스의 리로드와 유효성 등을 재확인하지 않도록 요구한단 의미
• 로컬 캐시가 없는 경우(캐시 서버가 로컬 캐시로부터 응답할 수 없는 경우)→504 Gateway Timeout 상태 코드 반환

must-revalidate

Cache-Control: must-revalidate

• 캐시 서버가 소유한 캐시 유효성 무조건 서버에 확인하도록 요구
• 프록시가 오리진 리소스 다시 요구 못하는 경우(오리진 서버에 도달하지 못하는 등)→504 Gateway Timeout 상태 코드 반환
• max-stale 디렉티브와 같이 사용시 max-stale의 효과 무시

proxy-revalidate

Cache-Control: proxy-revalidate

• must-revalidate와 의미는 같지만, 공유 캐시에 대해서만 적용(사설 캐시에는 적용하지 않음)

no-transform

Cache-Control: no-transform

• 리퀘스트와 리스폰스 어느 쪽에서도 캐시가 엔티티 바디의 미디어 타입을 변경하지 않도록 지정
  • 캐시 서버 등에 의한 이미지가 압축 방지 가능

cache-extension

Cache-Control: community=”UCI”

• Cache-Control 헤더 필드는 cache-extension 토큰으로 디렉티브 확장 가능
• 캐시 서버가 디렉티브를 모를 경우 무시됨→이해할 수 있는 캐시 서버에만 의미 있음
• 해당 예시는 community 디렉티브의 토큰 값이 UCI인 경우에 캐시를 주고받을 수 있게 설정하는 것으로 추정

Connection

Connection 헤더 필드에는 아래의 두 가지 역할 존재

• 헤더 전송 관리
• 지속적 접속(연결) 관리

1. 헤더 전송 관리

Connection: [헤더명]

• 클라이언트의 리퀘스트 혹은 서버의 리스폰스에서 Connection 헤더 필드 사용
• 필드 값로 지정된 헤더를 프록시가 전송하지 않게 설정
• 프록시에 적용되는 헤더 필드이므로 Hop-by-hop 헤더

2. 지속적 접속(연결) 관리

• HTTP/1.1에서는 지속적 접속이 디폴트로 설정(Keep-Alive)
  • 리퀘스트를 송신한 클라이언트는 접속이 계속 유지됨→접속 해제 없이 추가 리퀘스트 송신 가능
• 명시적으로 접속을 끊고 싶은 경우 Connection 헤더 필드에 Close라고 지정

Connection: Close

• HTTP/1.0에서는 디폴트가 아니기 때문에 Connection 헤더 필드에 Keep-Alive라고 지정

Connection: Keep-Alive

Date

Date: Tue, 03 Jul 2012 02:20:48 GMT

• HTTP 메시지를 생성한 날짜를 표시
• 위에 적은 Date 헤더 필드의 값은 RFC1123에 HTTP/1.1의 표준 날짜 포맷이라고 지정된 포맷으로 기입
  • 다른 포맷도 사용 가능

Pragma

HTTP/1.0의 후방 호환성만을 위해 정의된 헤더 필드

Pragma: no-cache

• 클라이언트의 리퀘스트에서만 사용
• 지정할 수 있는 형식은 위의 예가 끝(no-cache)
  • 캐시된 리소스의 리스폰스를 원하지 않는단 의미
• 사용 이유: 클라이언트와 오리진 서버 사이의 모든 중간 서버가 HTTP/1.1을 사용하지 않을 수 있음

Cache-Control: no-cache
Pragma: no-cache

• 그래서 위와 같이 보내는 경우 존재

Trailer

• 메시지 바디 뒤에 기술된 헤더 필드를 미리 전달하는 역할
• 청크 전송 인코딩(HTTP/1.1)을 사용한 경우에만 사용 가능

Transfer-Encoding

• 메시지 바디의 전송 코딩 형식을 지정
• HTTP/1.1에서는 청크 전송만이 정의됨(Transfer-Encoding: chunked)

HTTP/1.1 200 OK
Date: Tue, 03 Jul 2012 02:20:48 GMT
Cache-Control: public, max-age=604800
Content-Type: text/javascript; charset=utf-8
Expires: Tue, 10 Jul 2012 02:20:48 GMT
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block
Content-Encoding: gzip
Transfer-Encoding: chunked
Connection: Keep-Alive

Cf0
---Cf0(10진수로 3312) 바이트 정도의 데이터---
392
---392(10진수로 914) 바이트 정도의 데이터---
0

• 위의 메시지에서 Transfer-Encoding 헤더 필드를 chunked로 지정해 청크 전송 코딩이 유효한 상태
  • 3312바이트와 914바이트의 청크 데이터로 분할되어 전송

Upgrade

• 현재 요청하는 서버와 다른 서버가 HTTP 및 다른 프로토콜의 새로운 버전이 통신에 이용되는 경우에 사용

GET /index.htm HTTP/1.1
Upgrade: TLS/1.0
Connection: Upgrade

• 다른 서버와 통신할 때 TLS/1.0 프로토콜로 통신하라는 의미
  • 다른 서버에겐 유효하지 않은 헤더이므로 Connection 헤더로 제거
• Upgrade 헤더 필드가 달린 리퀘스트에 대한 리스폰스의 상태 코드는 101 Switching Protocols

Via

• 클라이언트와 서버 간 리퀘스트 혹은 리스폰스 메시지의 경로를 알기 위해(중간에 어느 서버가 있는지) 사용
• 프록시나 게이트웨이는 자신의 서버 정보를 Via 헤더 필드에 추가한 뒤에 메시지 전송
• 전송된 메시지의 추적, 리퀘스트 루프의 회피 등에 사용→프록시를 경유하는 경우에 반드시 추가해줘야 함
• 용도에 의해, TRACE 메소드와 연계해서 자주 사용됨

Warning

• HTTP/1.0 리스폰스 헤더인 Retry-After가 HTTP/1.1에서 변경된 것
• 리스폰스에 관한 추가 정보를 전달
  • 캐시에 관한 문제의 경고를 유저에게 전달하는 용도

Warning: [경고 코드] [경고한 호스트]:[포트 번호] "[경고문]" ([날짜])

• 위의 날짜는 생략 가능

경고 코드

• 110(Response is stale)
  • 프록시가 유효기간이 지난 리소스 반환
• 111(Revalidation failed)
  • 프록시가 리소스의 유효성 재확인에 실패(서버에 도달할 수 없는 등의 이유로)
• 112(Disconnection operation)
  • 프록시가 네트워크로부터 고의로 끊겨 있는 상태
• 113(Heuristic expiration)
  • 리스폰스가 24시간 이상 경과하고 있는 경우(캐시의 유효기한을 24시간 이상으로 설정한 경우)
• 199(Miscellaneous warning)
  • 임의의 경고문
• 214(Transformation applied)
  • 프록시가 인코딩과 미디어 타입 등에 무언가의 처리를 한 경우
• 299(Miscellaneous persistent warning)
  • 임의의 경고문