제 6장. HTTP 헤더

HTTP 헤더 필드는 그 용도에 따라 4종류로 분류할 수 있다.

또한, HTTP 헤더 필드는 캐시와 비캐시 프록시의 동작을 정의하기 위해서 두 가지 카테고리로 분류되어 있다.

• End-to-end 헤더
  요청이나 응답의 최종 수신자에게 전송
• Hop-by-hop 헤더
  한 번 전송에 대해서만 유효하고 캐시와 프록시에 의해서 전송되지 않는 것도 있음

 

📘 1. 일반적 헤더 필드(General Header Fields)

• 요청 메시지와 응답 메시지 둘 다 사용되는 헤더

헤더 필드 명	설명
Cache-Control	캐싱 동작 지정
Connection	Hop-by-hop 헤더. 커넥션 관리
Date	메시지 생성 날짜
Pragma	메시지 제어
Trailer	메시지의 끝에 있는 헤더의 일람
Transfer-Encoding	메시지 바디의 전송 코딩 형식 지정
Upgrade	다른 프로토콜에 업그레이드
Via	프록시 서버에 관한 정보
Warning	에러 통지

🔎 1-1. Cache-Control

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

[캐시 요청 디렉티브]

디렉티브	파라미터	설명
no-cache	없음	오리진 서버에 강제적인 재검증
no-store	없음	캐시는 요청과 응답의 일부분을 보존해서는 안됨
max-age = [초]	필수	응답의 최대 age 값
max-state( = [초])	생략 가능	기한이 지난 응답을 수신
min-fresh = [초]	필수	지정한 시간 이후에 변경된 응답을 보냄
no-transform	없음	프록시는 미디어 타입을 변환해서는 안됨
only-if-cached	없음	캐시에서 리소스를 취득
cache-extension	-	새로운 디렉티브를 위한 토큰

[캐시 응답 디렉티브]

디렉티브	파라미터	설명
public	없음	어딘가에 응답 캐시가 가능
private	생략 가능	특정 유저에 대해서만 응답
no-cache	생략 가능	유효성의 재확인 없이는 캐시는 사용해서는 안됨
no-store	없음	캐시는 요청과 응답의 일부분을 보존해서는 안됨
no-transform	없음	프록시는 미디어 타입을 변경해서는 안됨
must-revalidate	없음	캐시가 가능하지만 오리진 서버에 리소스의 유효성을 재확인을 요구
proxy-revalidate	없음	중간 캐시 서버에 대해서 캐시했던 응답의 유효성의 재확인을 요구
max-age = [초]	필수	응답의 최대 Age 값
s-maxage = [초]	필수	공유 캐시 서버의 응답 최대 Age 값
cache-extension	-	새로운 디렉티브를 위한 토큰

🔎 1-2. Connection

• 프록시에 더 이상 전송하지 않는 헤더 필드를 지정

Connection: 더 이상 전송하지 않는 헤더 필드 명

• 지속적 접속 관리

Connectin: Close // 서버 측에서 명시적으로 접속을 끊고 싶은 경우
Connection: Keep-Alive // 지속적 접속을 하고 싶은 경우

🔎 1-3. Date

• HTTP 메시지를 생성한 날짜를 나타냄

🔎 1-4. Pragma

• HTTP/1.1 보다 오래된 버전의 흔적으로 HTTP/1.0 와의 후방 호환성만을 위해서 정의되어 있는 헤더 필드
• 클라이언트는 캐시 된 리소스의 응답을 원하지 않음을 모든 중간 서버에 알리기 위해 사용

Pragma: no-cache

🔎 1-5. Trailer

• 메시지 바디의 뒤에 기술되어 있는 헤더 필드를 미리 전달할 수 있음
• Trailer 헤더 필드에 Expires를 지정하고 있고, 메시지 바디의 뒤에 Expires 헤더 필드가 나타남

...
Trailer: Expires
... (메시지 바디) ...
0
Expires: Wed, 31 May 2023 23:59:59 GMT

🔎 1-6. Transfer-Encoding

• 메시지 바디의 전송 코딩 형식을 지정하는 경우에 사용

Transfer-Encoding: chunked

🔎 1-7. Upgrade

• HTTP 및 다른 프로토콜의 새로운 버전이 통신에 이용되는 경우에 사요
• Upgrade 헤더 필드를 사용하는 경우는 Connection: Upgrade도 지정할 필요가 있음

Upgrade: TLS/1.0
Connection: Upgrade

🔎 1-8. Via

• 클라이언트와 서버 간의 요청 혹은 응답 메시지의 경로를 알기 위해서 사용
• Via 헤더 필드는 전송된 메시지의 추적과 요청 루프의 회피 등에 사용되기 때문에 프록시를 경유하는 경우에는 반드시 부가할 필요가 있음

🔎 1-9. Warning

• HTTP/1.0 응답 헤더(Retry-After)가 HTTP/1.1에서 변경된 것으로 응답에 관한 추가 정보를 전달
• 기본적으로 캐시에 관한 문제의 경고를 유저에게 전달

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

 

 

📘 2. 요청 헤더 필드(Request Header Fields)

• 클라이언트 측에서 서버 측으로 송신된 요청 메시지에 사용되는 헤더
• 요청의 부가적 정보와 클라이언트의 정보, 응답의 콘텐츠에 관한 우선 순위 등을 부가

헤더 필드명	설명
Accept	유저 에이전트가 처리 가능한 미디어 타입
Accept-Charset	문자셋 우선 순위
Accept-Encoding	콘텐츠 인코딩 우선 순위
Accept-Language	언어(자연어) 우선 순위
Authorization	웹 인증을 위한 정보
Expect	서버에 대한 특정 동작에 기대
From	유저의 메일 주소
Host	요구된 리소스의 호스트
If-Match	엔티티 태그의 비교
If-Modified-Since	리소스의 갱신 시간 비교
If-None-Match	엔티티 태그의 비교(If-Match의 반대)
If-Range	리소스가 갱신되지 않은 경우에 엔티티의 바이트 범위의 요구를 송신
If-Unmodified-Since	리소스의 갱신 시간 비교(If-Modified-Since의 반대)
Max-Forwards	최대 전송 홉 수
Proxy-Authorization	프록시 서버의 클라이언트 인증을 위한 정보
Range	엔티티 바이트 범위 요구
Referer	리퀘스트중의 URI를 취득하는 곳
TE	전송 인코딩의 우선 순위
User-Agent	HTTP 클라이언트 정보

 

 

📘 3. 응답 헤더 필드(Response Header Fields)

• 서버 측에서 클라이언트 측으로 송신한 응답 메시지에 사용되는 헤더
• 응답의 정보와 서버의 정보, 클라이언트의 추가 정보 요구 등을 부가

헤더 필드명	설명
Accept-Ranges	바이트 단위의 요구를 수신할 수 있는지 없는지 여부
Age	리소스의 지정 경과 시간
Etag	리소스 특정하기 위한 정보
Location	클라이언트를 지정한 URI에 리다이렉트
Proxy-Authenticate	프록시 서버의 클라이언트 인증을 위한 정보
Retry-After	요청 재시행의 타이밍 요구
Server	HTTP 서버 정보
Vary	프록시 서버에 대한 캐시 관리 정보 캐시를 컨트롤 하기 위해서 사용 오리진 서버가 프록시 서버에 로컬 캐시를 사용하는 방법에 대한 지시를 전달
WWW-Authenticate	서버의 클라이언트 인증을 위한 정보

 

 

📘 4. 엔티티 헤더 필드(Entity Header Fields)

• 요청 메시지와 응답 메시지에 포함된 엔티티에 사용되는 헤더
• 콘텐츠 갱신 시간 등의 엔티티에 관한 정보를 부가

헤더 필드명	설명
Allow	리소스가 제공하는 HTTP 메서드
Content-Encoding	엔티티 바디에 적용되는 콘텐츠 인코딩
Content-Language	엔티티의 자연어
Content-Length	엔티티 바디의 사이즈 (단위: 바이트)
Content-Location	리소스에 대응하는 대체 URI
Content-MD5	엔티티 바디의 메시지 다이제스트 메시지 바디가 변경되지 않고 도착했는지 확인하기 위해 MD5 알고리즘에 의해서 생성된 값을 전달
Content-Range	엔티티 바디의 범위 위치
Content-Type	엔티티 바디의 미디어 타입
Expires	엔티티 바디의 유효기한 날짜
Last-Modified	리소스의 최종 갱신 날짜

 

 

📘 5. HTTP/1.1 이외의 헤더 필드

• 지금까지는 RFC2616에 정의된 47 종류의 헤더 필드를 살펴봄
• 하지만, 쿠키와 Set-Cookie, Content-Disposition과 같은 것도 폭 넓게 사용되고 있는 것이 있음
• 이러한 비표준 헤더 필드는 RFC4229 HTTP Header Field Registrations에 정리되어 있음

헤더 필드명	설명
Set-Cookie	상태 관리 개시를 위한 쿠키 정보 (응답)
Cookie	서버에서 수신한 쿠키 정보 (요청)
X-Frame-Option	다른 웹 사이트의 프레임에서 표시를 제어하는 것 클릭 재킹(Click Jacking)이라는 공격을 막는 것을 목적으로 함
X-XSS-Protection	크로스 사이트 스크립팅(XSS) 대책으로서 브라우저의 XSS 보호 기능을 제어하는 HTTP 응답 헤더
DNT	Do Not Track(DNT)라는 뜻으로 개인 정보 수집을 거부하는 의사를 나타내는 HTTP  요청 헤더
P3P	웹 사이트 상의 프라이버시 정책에 P3P(The Platform for Privacy Preferences)를 사용하는 것 프로그램이 읽을 수 있는 형태로 나타내기 위한 HTTP 요청 헤더