[6장] HTTP 헤더

HTTP의 리퀘스트와 리스폰스에는 반드시 HTTP 헤더가 포함된다.

6.1 HTTP 메시지 헤더

HTTP 프로토콜의 리퀘스트와 리스폰스에는 반드시 메시지 헤더가 포함된다.

• 메시지 헤더
  : 클라이언트나 서버가 리퀘스트나 리스폰스를 처리하기 위한 정보를 포함한다

• 리퀘스트의 HTTP 메시지
  : 메소드 + URI + HTTP 버전 + HTTP 헤더 필드로 구성

• 리스폰스의 HTTP 메시지
  : HTTP 메시지 + HTTP 버전 + 상태코드(코드와 설명) + HTTP 헤더 필드로 구성

• HTTP 헤더 필드
  : HTTP 메시지에 대한 정보를 갖는다. 리퀘스트와 리스폰스 모두에 존재
  : HTTP 버전과 확장 사양에 따라 지원 내용이 달라진다

6.2 HTTP 헤더 필드

HTTP 헤더 필드는 메시지 바디의 크기, 사용하고 있는 언어, 인증 정보 등을 포함한다.

• HTTP 헤더 필드의 구조
  [ 헤더 필드 명 : 필드 값 ]

  Ex. Content-Type:text/html
  하나의 헤더 필드가 여러 개의 필드 값을 가질 수도 있다!

• HTTP 헤더 필드의 종류
  (1) 일반적 헤더 필드 (General Header Fields)
  : 리퀘스트 메시지와 리스폰스 메시지 둘 다 사용되는 헤더
  (2) 리퀘스트 헤더 필드 (Request Header Fields)
  : 리퀘스트 메시지에 사용되는 헤더
  : 리퀘스트의 부가적 정보 / 클라이언트의 정보 / 리스폰스 콘텐츠에 관한 우선순위 포함
  (3) 리스폰스 헤더 필드 (Response Header Fields)
  : 리스폰스 메시지에 사용되는 헤더
  : 리스폰스의 정보 / 서버의 정보 / 클라이언트의 추가 정보 포함
  (4) 엔티티 헤더 필드 (Entity Header Fields)
  : 리퀘스트 메시지와 리스폰스 메시지에 포함된 엔티티에 사용되는 헤더
  : 콘텐츠 갱신 시간 등 엔티티에 대한 정보를 포함

• HTTP/1.1 헤더 필드 이외에도 비표준 헤더필드 (RFC4229 HTTP Header Field Registrations)가 존재

• HTTP 헤더 필드의 카테고리
  : 캐시와 비캐시 프록시의 동작을 정의하기 위해 분류
  (1) End-to-end 헤더
  : 리퀘스트나 리스폰스의 최종 수신자에게 전송된다.
  : 캐시에서 구축된 리스폰스 중 보존되며, 다시 전송해야 하는 구조
  (2) Hop-by-hop 헤더
  : 한 번 전송에 대해서만 유효.
  : 캐시와 프록시에 의해 전송되지 않기도 한다.

6.3 HTTP/1.1 일반 헤더 필드

리퀘스트 메시지와 리스폰스 메시지 양쪽에서 사용되는 헤더

Cache-Control

• 디렉티브 명령으로 캐싱 동작 지정
  : 디렉티브 여러개일 경우 ","로 구분
  : 리퀘스트, 리스폰스 할 때에 사용가능 - 리퀘스트 디렉티브, 리스폰스 디렉티브로 나뉜다

• 캐시가 가능한지 여부를 나타내는 디렉티브
  (1) public : 다른 유저에게 돌려줄 수 있는 캐시를 해도 좋다는 것을 명시적으로 나타낸다
  (2) private : 리스폰스는 특정 유저만을 대상으로 하고 있다는 것을 나타낸다
  (3) no-cache
  : 캐시로부터 오래된 리소스가 반환되는 것을 막기 위해 사용된다
  : 클라이언트의 리퀘스트에 사용되면 중간 캐시가 오리진 서버까지 리퀘스트를 전송해야함
  : 서버의 리스폰스에 사용되면 캐시 서버는 리소스를 저장할 수 없고, 오리진 서버는 캐시 서버가 이후 리퀘스트에서 리소스 유효성을 확인하지 않으면 해당 리스폰스를 사용하지 못하게 함
  : 서버 리스폰스로 no-cache에 지정된 헤더 필드만 캐시할 수 없다.

• 캐시로 보존 가능한 것을 제어하는 디렉티브
  (1) no-store
  : 리퀘스트 혹은 리스폰스에 기밀 정보가 포함되어 있음
  : 캐시는 리퀘, 리스의 일부분을 로컬 스토리지에 보존 안되도록 지정

• 캐시 기한이나 검증을 지정하는 디렉티브
  (1) s-maxage : 여러 유저가 이용할 수 있는 공유 캐시 서버에만 적용 가능한 max-age 디렉티브
  (2) max-age
  : (클라이언트 리퀘스트) 지정되었던 값보다 새로운 경우에는 캐시되었던 리소스를 받을 수 없고, 지정한 값이 0이면 캐시 서버는 리퀘스트를 항상 오리진 서버에 넘겨야 한다.
  : (서버 리스폰스) 캐시 서버가 유효성의 재확인을 하지 않고 리소스를 캐시에 보존해두는 최대 시간을 나타낸다
  (3) min-fresh : 캐시된 리소스가 적어도 지정된 시간은 최신 상태의 것을 반환하도록 캐시 서버에 요구
  (4) max-state : 캐시된 리소스의 유효기한이 끝났더라도 받아들일 수 있다
  (5) only-if-cached : 캐시 서버에서 리스폰스의 리로드와 유효성을 재확인하지 않도록 요구하며, 캐시 서버가 로컬 캐시로부터 응답할 수 없다면 '504 Gateway Timeout' 상태 반환
  (6) must-revalidate
  : 리스폰스의 캐시가 현재도 유효한지 아닌지의 여부를 오리진 서버에 조회 요구.
  : 프록시가 오리진 서버에 도달할 수 없고 리소스를 다시 요구할 수 없다면 캐시는 클라이언트에 '504 Gateway Timeout' 상태 반환
  : must-revalidate 사용 중이라면, 리퀘스트의 max-state는 무시된다
  (7) proxy-ravalidate : 모든 캐시 서버에 대해 이후의 리퀘스트로 해당 리스폰스 반환할 경우, 반드시 유효성 재확인 요구
  (8) no-transform : 리퀘스트와 리스폰스 모두 캐시가 엔티티 바디의 미디어 타입을 변경하지 않도록 지정 (=캐시 서버에 의한 이미지 압축 방지)

• Cache-Control 확장
  : cache-extension 토큰을 이용, 디렉토리 호학장 가능

Connection

• 프록시에 더 이상 전송하지 않는 헤더 필드를 지정
  : hop-by-hop 헤더로 지정

• 지속적 접속 관리
  : HTTP/1.1에서 지속적 접속은 default 값
  : 리퀘스트를 송신한 클라이언트의 접속은 계속 유지되고, 추가 리퀘스트를 송신한다
  : 서버에서 명시적으로 접속을 끊고 싶다면 Connection 헤더 필드에 Close를 지정

  HTTP/1.1 이전에서는 지속적 접속을 원한다면 Connection 필드에 Keep-Alive 지정 필요

Date

• HTTP를 생성한 날짜를 나타낸다

Pragma

• HTTP/1.0의 후방 호환성을 위해 정의된 헤더필드
  : 클라이언트의 리퀘스트에서만 사용가능
  : Pragma: no-cache 의 형식만 지정 가능
  : 캐시된 리소스의 리스폰스를 원하지 않음을 모든 중간 서버에 알리기 위해 사용한다

Trailer

• 메시지 바디의 뒤에 기술되어 있는 헤더 필드를 미리 전달한다
  : HTTP/1.1의 청크 전송 인코딩을 사용하는 경우 사용

Transfer-Encodiing

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

Upgrade

• HTTP 및 다른 프로토콜의 새로운 버전이 통신에 이용되는 경우에 사용
  : 지정하는 대상이 전혀 다른 통신 프로토콜이라도 상관 X
  : Upgrade가 있는 리퀘스트에 대해 서버는 상태 코드 101 Switching Protocol 리스폰스로 응답 가능

Via

• 클라이언트와 서버 간의 리퀘스트 / 리스폰스 메시지의 경로 추적을 위해 사용
  : traceroute와 메일의 Received 헤더 기능과 유사
  : 전송된 메시지의 추적과 리퀘스트 루프 회피에 사용 = 프록시 경유할 때 반드시 필요
  : 배송 경로를 알기 위해 TRACE 메소드와 연계해서 자주 사용

Warning

• 리스폰스 헤더 Retry-After의 변형
  : 리스폰스에 관한 추가 정보 전달 = 보통 캐시에 관한 문제의 경고를 유저에게 전달
  : HTTP/1.1에 7개의 권장 경고 코드가 정의되어 있으며, 확장 가능하기에 이후 코드 추가 가능

6.4 리퀘스트 헤더 필드

클라이언트 측에서 서버 측으로 송신된 리퀘스트 메시지에 사용하는 헤더
: 리퀘스트의 부가 정보, 클라이언트의 정보, 리스폰스의 콘텐츠에 관한 우선 순위 추가

Accept

• 유저 에이전트에 처리할 수 있는 미디어 타입과 미디어 타입의 상대 우선순위 전달
  : 텍스트 파일, 이미지 파일, 동영상 파일, 애플리케이션용 바이너리 파일 등 '

• 서버가 복수의 콘텐츠 반환할 수 있다면
  : 가장 높은 품질 계수의 미디어 타입으로 변환 필요
  : 우선 순위는 q로 품질 지수 표시

Accept-Charset

• 유저 에이전트에서 처리할 수 있는 문자셋
  : 문자셋의 상대 우선 순위를 전달하기 위해 사용
  : 문자셋은 한번에 여러개 지정 가능
  : 품질 지수에 의해 우선 순위 표시 가능
  : 서버 구동형 네고시에이션에 사용

Accept-Encoding

• 유저 에이전트가 처리할 수 있는 컨텐츠 로딩과 컨텐츠 코딩의 상대 우선 순위 전달
  : 컨텐츠 코딩은 한번에 여러개 지정 가능
  (gzip, compress, deflate, identity 등)
  : 품질 지수에 의해 우선 순위 표시 가능
  : 애스터리스크 (*) 로 모든 인코딩 포맷 가리킬 수 있다

Accept-Language

• 유저 에이전트가 처리할 수 있는 자연어 세트와 자연어 세트의 상대 우선 순위 전달
  : 자연어 세트는 한번에 여러개 지정 가능

Authorization

• 유저 에이전트의 인증 정보를 전달
  : 서버에 인증 받으려 하는 유저 에이전트는 생태코드 401 리스폰스 뒤에 리퀘스트 Authorization 헤더 필드를 포함한다

Expect

• 클라이언트가 서버에 특정 동작 요구를 전달
  : 기대하는 요구에 서버가 응답하지 못해 에러가 발생할 경우, 상태코드 417 Expectation Failed를 반환한다

From

• 유저 에이전트를 사용하고 있는 유저의 메일 주소를 전달한다
  : 기본적으로 검색 엔진 등의 에이전트 책임자에게 연락처 메일 주소를 나타내는 목적

Host

• 리퀘스트한 리소스의 인터넷 호스트와 포트 번호를 전달한다
  : 유일한 필수 헤더 필드
  : 1대의 서버에서 복수의 도메인을 할당할 수 있는 가상 호스트 구조와 연관된다
  : 어느 도메인에 대한 리퀘스트인지를 명시하기 위해 Host 헤더 필드 리퀘스트에 대한 Host 명을 기재한다
  : 만약 서버의 호스트 명이 설정되어 있지 않은 경우, 값을 비워서 보낸다

If-Match

조건부 리퀘스트
: 지정된 조건에 맞는 경우에만 서버가 리퀘스트를 받는다

• 서버 상의 리소스를 특정하기 위해 엔티티 태그(ETag)값을 전달한다
  : If-Match의 필드값과 리소스의 ETag가 일치할 경우에만 서버가 리퀘스트를 받는다
  : 불일치할 경우, 412 리스폰스 반환
  : 필드값에 "*" 지정하면 ETag에 상관없이 리소스가 존재하면 리퀘스트 처리 가능

If-Modified-Since

• 리소스 갱신 날짜가 필드값보다 새롭지 않다면 리퀘스트를 받아들인다
  : 만약 필드 지정 날짜 이후 지정 리소스가 갱신되어있지 않다면 304 리스폰스 반환

If-None-Match

• 필드값에 지정된 ETag 값이 지정된 리소스의 ETag 값과 일치하지 않으면 리퀘스트를 받아들인다
  : If-Match와 반대로 동작

If-Range

• 필드값과 지정한 리소스의 ETag 값 혹은 날짜가 일치하면 Range 리퀘스트로 처리한다
  : 일치하지 않을 경우 리소스 전체 반환

If-Unmodified-Since

• 지정된 리소스가 필드 값에 지정된 날짜 이후에 갱신되어 있지 않은 경우에만 리퀘스트 받아들인다
  : If-Modified-Since와 반대로 동작

Max-Forwards

• TRACE 또는 OPTIONS 메소드에 의한 리퀘스트를 할 때 전송해도 좋은 서버 수의 최대치를 10진수 정수로 지정한다
  : 서버는 다음 리퀘스트 전송할 때 Max-Forwards - 1을 세틓한다
  : 만약 필드값이 0이라면 전송하지 않고 리스폰스를 반환한다
  : 리퀘스트가 프록시 서버 등 여러 대의 서버를 경유할 때, 도중에 리퀘스트 전송이 실패하여 클라이언트에게 리스폰스가 돌아오지 않는 경우를 커버한다 (서버 상황 알림)

Proxy-Authorization

• 프록시 서버에서의 인증 요구를 받아들인 때에 인증에 필요한 클라이언트의 정보를 전달
  : 클라이언트와 프록시 사이에 인증이 이루어진다는 점에서 HTTP 액세스 인증과 차이

Range

• 리소스의 일부만 취득하는 Range 리퀘스트를 할 때 지정 범위를 전달한다
  : 서버가 리퀘스트를 처리할 수 있을 때 206 리스폰스를 반환
  : 없을 때 200 OK 리스폰스로 리소스 전체를 반환

Referer

• 리퀘스트가 발생한 본래 리소스의 URI를 전달
  : 브라우저의 주소창에 직접 입력한 경우와 보람상 바람직하지 않은 경우 안보내도 OK
  : 본래 리소스의 URI에 ID, Password 등이 포함된 경우 다른 서버에 누설 될 수 있음

TE

• 리스폰스로 받을 수 있는 전송 코딩의 형식과 상대 우선 순위를 전달
  : 전송 코딩에 적용
  : 전송 코딩 지정 이외에 Trailer를 동반하는 청크 전송 인코딩 형식의 지정이 가능
  (필드값에 "trailer" 기록)

User-Agent

• 리퀘스트를 생성한 브라우저와 유저 에이전트의 이름을 전달
  : 프록시 경유하는 리퀘스트의 경우 프록시 서버의 이름이 부가될 수 O

6.5 리스폰스 헤더 필드

서버 측에서 클라이언트 측으로 송신된 리스폰스 메시지에 사용하는 헤더
: 리스폰스의 부가 정보, 서버의 정보, 클라이언트에 부가 정보 요구 등

Accept-Ranges

• Range 리퀘스트를 접수할 수 있는지의 여부를 전달

  Range 리퀘스트 : 서버가 리소스의 일부분만 지정해서 취득할 수 있는 리퀘스트

Age

• 오리진 서버에서 얼마나 오래 전에 리스폰스가 생성되었는지 전달
  : 단위값은 초

• 리스폰스한 서버가 캐시 서버인 경우
  : 캐시된 리스폰스가 다시 실증되었던 때부터 검증한 시간

• 프록시가 리스폰스를 생성한 경우, Age 헤더 필드가 필수!

ETag (= 엔티티 태그)

• 일의적으로 리소스를 특정하기 위한 문자열을 전달
  : 서버는 리소스마다 ETag 값을 할당한다
  : 리소스가 갱신되지 않으면 ETag 값 갱신할 필요 없다

• 도중에 다운로드가 끊긴 경우, ETag 값을 참조해 리소스를 특정한다.

강한 ETag, 약한 ETag

1. 강한 ETag : 엔티티가 아주 조금 다르더라도 반드시 값이 변화한다.
2. 약한 ETag : 리소스가 같다는 것만을 나타낸다.
   의미가 다른 리소스일 경우만 값이 변화하며, 값의 앞부분에 "W/"가 붙는다.

Location

• 리스폰스의 수신자에 대해 Request-URI 이외의 리소스 액세스를 유도하는 경우에 사용

Proxy-Authenticate

• 프록시 서버에서의 인증 요구를 클라이언트에게 전달
  : 클라이언트와 프록시 사이에서 인증이 이루어진다는 점에서 HTTP 액세스 인증과 차이

Retry-After

• 클라이언트가 일정 시간 후에 리퀘스트를 다시 시행해야하는지를 전달
  : 줄로 503 상태코드 리스폰스나 3xx Redirect 리슷폰스와 함께 사용

Server

• 서버에 설치되어 있는 HTTP 서버의 소프트웨어 전달
  : 단순 명칭 뿐 아니라, 버전, 옵션에 대해 기재하기도 한다

Vary

• 캐시를 컨트롤하기 위해 사용
  : 오리진 서버가 프록시 서버에 로컬 캐시를 사용하는 방법에 대한 지시 전달

• 오리진 서버로부터 Vary에 지정된 리스폰스를 받아들인 프록시 서버는 이후 캐시된 리퀘스트와 같은 vary에 지정된 헤더 필드를 가진 리퀘스트에 대해서만 캐시 반환 가능

• 같은 리소스에 대한 리퀘스트라도, Vary에 지정된 헤더 필드가 다른 경우 오리진 서버로부터 리소스 취득해야한다

WWW-Authenticate

• HTTP 액세스 인증에 사용
  : Request-URI에 지정된 리소스에 적용할 수 있는 인증 스키마와 파라미터를 나타내는 challenge를 전달

• 상태코드 401 리스폰스에 반드시 포함된다

6.6 엔티티 헤더 필드

리퀘스트 메시지와 리스폰스 메시지에 포함된 엔티티에 사용되는 헤더
: 콘텐츠의 갱신 시간과 같은 엔티티에 대한 정보를 포함한다

Allow

• Request-URI에 지정된 리소스가 제공하는 메소드의 일람 전달
• 서버가 받을 수 없는 메소드를 수신한 경우
  : 405 상태코드 리스폰스와 함께 수신 가능한 메소드 일람 전달

Content-Encoding

• 서버가 엔티티 바디에 대해서 실시한 콘텐츠 코딩 형식 지정
  : 정보가 누락되지 않도록 압축할 것을 지시
  : Gzips, Compress, Deflate, Identity 의 4가지 콘텐츠 코딩 형식 사용

Content-Language

• 엔티티 바디에 사용된 자연어를 전달

Content-Length

• 엔티티 바디의 크기(바이트 단위)를 전달
  : 엔티티 바디에 전송 코딩이 실시된 경우 해당 헤더 필드를 사용하지 않는다

Content-Location

• 메시지 바디에 대응하는 URI를 전달
  : 메시지 바디로 반환된 리소스의 URI를 나타낸다는 점에서 Location 헤더 필드와 차이

Content-MD5

• 메시지 바디가 변경되지 않고 도착했는지 확인하기 위해 MD5 알고리즘에 의해 생성된 값 전달
  : 유효성을 확인하기 위해 수신한 클라이언트 측에서 메시지 바디에 같은 MD5 알고리즘 실행
  : 단, 악의적인 변조는 검출할 수 없다.

Content-Range

• 범위를 지정해서 일부분만을 리퀘스트하는 Range 리퀘스트에 대해 리스폰스 할 때 사용
  : 리스폰스로 보낼 엔티티가 어느 부분에 해당하는가?

Content-Type

• 엔티티 바디에 포함되는 오브젝트의 미디어 타입을 전달

Expires

• 리소스의 유효 기한 날짜 전달
  : 캐시 서버가 수신할 경우, 필드 값으로 지정된 날짜까지 리스폰스의 복사본을 유지하고 리퀘스트에는 캐시를 전달한다. 지정날짜가 지난 경우엔 오리진 서버에 리소스를 얻으러 간다

• 오리진 서버가 캐시 서버에 캐시되는 것을 원하지 않는다면 Date 헤더 필드의 필드 값과 같은 날짜로 지정한다.

Last-Modified

• 리소스가 마지막으로 갱신되었던 날짜 정보를 전달한다.
  : 기본적으로 Request-URI가 지정된 리소스가 갱신되었던 날짜
  : 동적 데이터를 다룰 경우, 데이터의 최종 갱신 날짜가 되기도 한다

6.7 쿠키 헤더 필드

유저 식별과 상태 관리에 쿠키 사용.
쿠키 호출 시 쿠키의 유효 기한과 송신지 도메인, 경로, 프로토콜 등을 체크하기 때문에 데이터 도난의 위험이 적다.

Set-Cookie

• 서버가 클라이언트에 대해 상태 관리를 시작할 때 댜양한 정보를 전달

• Expires 속성
  : 브라우저가 쿠키를 송출할 수 있는 유효 기간 지정
  : 생략할 경우 브라우저 세션이 유지되고 있는 동안만 쿠키 유효
  : 한번 송출한 클라이언트의 쿠키는 서버에서 명시적으로 삭제할 수 없다 -> 덮어쓰는 방식으로 삭제

• Path 속성
  : 쿠키를 송출하는 범위를 특정 디렉토리에 한정

• Domain 속성
  : 지정된 도메인 명은 후방 일치가 된다.
  : 명시적으로 여러 도메인에 대해 송출하는 경우를 제외하고, 지정하지 않는 것이 안전

• Secure 속성
  : 웹 페이지가 HTTPS에서 열렸을 때에만 쿠키 송출을 제한한다.

• HttpOnly 속성
  : 자바스크립트를 경유하는 방식으로 쿠키를 취득하지 못하도록 막는다.
  : 크로스 사이트 스크립팅(XSS)로부터 쿠키의 도청을 막는 것이 목적
  : XSS자체를 막는 것은 아니다

Cookie

• 클라이언트가 HTTP의 상태 관리 지원을 원할 때 서버로부터 수신한 쿠키를 이후의 리퀘스트에 포함해서 전달한다.
• 쿠키를 여러개 수신할 때, 쿠키를 여러개 보내는 것도 가능

6.8 기타 헤더 필드

웹 서버와 브라우저의 기능에 대해 독자적인 헤더 필드 존재

X-frame-Option

• 다른 웹 사이트의 프레임에서 표시를 제어하는 HTTP 리스폰스 헤더
  : 클릭 재킹(click jacking) 공격 막는 것이 목적

클릭 재킹
: 웹 사용자가 자신이 클릭하고 있다고 인지하는 것과 다른 것을 클릭하게 속이는 해킹 기법

• 모든 웹 서버에서 설정하는 것이 바람직
  
  

X-XSS-Protection

• 크로스 사이트 스크립팅 대첵
  : 브라우저의 XSS 보호 기능을 제어하는 HTTP 리스폰스 헤더

DNT

• Do Not Track
  : 개인 정보 수집을 거부를 나타내는 HTTP 리퀘스트 헤더
  : 타깃 광고 등에 이용되는 트래킹 거부 의사를 나타내기 위한 방법 중 하나
  : 유효성을 유지하기 위해 웹 서버에서 DNT를 지원해야 한다

P3P

• 웹 사이트 상의 프라이버시 정책에 P3P를 사용하는 것
  : 프로그램이 읽을 수 있는 형태로 나타내기 위한 HTTP 리스폰스 헤더