6장 HTTP 헤더

6.1 HTTP 메시지 헤더

HTTP 프로토콜의 리퀘스트, 리스폰스에는 반드시 메시지 헤더가 포함되어 있는데 메시지 헤더에는 클라이언트나 서버가 리퀘스트나 리스폰스를 처리하기 위한 정보가 들어있다. 이러한 정보의 대부분은 클라이언트를 이용하는 사용자가 직접 볼 필요는 없다.

• 리퀘스트의 HTTP 메시지 : 메소드, URI, HTTP 버전, HTTP 헤더 필드 등으로 구성되어 있다.

• 리스폰스의 HTTP 메시지 : HTTP 메시지와 HTTP 버전, 상태코드, HTTP 헤더 필드 등으로 구성되어 있다.

이중 가장 다양한 정보를 가지고 있는 것이 HTTP 헤더 필드로 헤더 필드는 리퀘스트와 리스폰스 양쪽에 모두 존재하고 HTTP 메시지에 관한 정보를 가지고 있다.

6.2 HTTP 헤더 필드

1. HTTP 헤더 필드는 중요한 정보를 전달한다.

   HTTP 메시지를 구성하는 요소의 하나로 클라이언트와 서버간의 통신에서 리퀘스트에도 리스폰스에도 사용되고 있고, 부가적으로 중요한 정보를 전달하는 역할을 담당하고 있다.

2. HTTP 헤더 필드의 구조

   HTTP 헤더 필드는 헤더 필드 명과 필드 값으로 구성되어 있고 콜론(:)으로 나뉘어져 있다. 헤더 필드명 : 필드값

3. 4종류의 HTTP 헤더 필드

   a. 일반적 헤더 필드 : 리퀘스트 메시지와 리스폰스 메시지 둘 다 사용되는 헤더이다.

   b. 리퀘스트 헤더 필드 : 리퀘스트 메시지에 사용되는 헤더로 리퀘스트의 부가적 정보와 클라이언트의 정보, 리스폰스의 콘텐츠에 관한 우선 순위 등을 부가한다.

   c. 리스폰스 헤더 필드 : 리스폰스 메시지에 사용되는 헤더로 리스폰스의 정보와 서버의 정보, 클라이언트의 추가 정보 요구 등을 부가한다.

   d. 엔티티 헤더 필드 : 리퀘스트, 리스폰스 메시지에 포함된 엔티티에 사용되는 헤더로 콘텐츠 갱신 시간 등의 엔티티에 관한 정보를 부가한다.

4. HTTP/1.1 헤더 필드 일람

   

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

   헤더가 RFC2616에서 정의된 47종류만 있는 것은 아니다. 쿠키와 Set-Cookie, Content-Disposition과 같이 그 외에 RFC에 정의되어 폭 넓게 사용되고 있는 것도 있다. 이런 비표준 헤더 필드는 RFC4229 HTTP Header Field Registrations에 정리되어 있다.

6. End-to-end 헤더와 Hop-by-hop 헤더
7. End-to-end : 리퀘스트나 리스폰스의 최종 수신자에게 전송된다.
8. Hop-by-hop: 한 번 전송에 대해서만 유효하고 캐시와 프록시에 의해서 전송되지 않는 것도 있다.

6.3 HTTP/1.1 일반 헤더 필드

1.Cache-Control

이 헤더는 디렉티브로 불리는 명령을 사용하여 캐싱 동작을 지정한다. 디렉티브에는 파라미터가 있는 것과 없는 것도 있고 여러개의 디렉티브를 지정하는 경우에는 콤마로 구분한다.

[● 캐시가 가능한지 여부를 나타내는 디렉티브]

1. public 디렉티브 : 캐시를 해도 좋다
2. private 디렉티브 : 리스폰스는 특정 유저만을 대상으로 하고 있다. 따라서 특정 유저를 위해서 리소스를 캐시할 수 있지만 다른 유저로부터 같은 리퀘스트가 온다고 하더라도 그 캐시를 반환하지 않음
3. no-cache 디렉티브 : 캐시로부터 오래된 리소스가 반환되는 것을 막기 위해 사용된다. 클라이언트의 리퀘스트에 사용된 경우 캐시된 리스폰스를 클라이언트가 받아들이지 않음을 의미하고 서버의 리스폰스에 사용된 경우 캐시서버는 리소스를 저장할 수 없다.

[● 캐시로 보존 가능한 것을 제어하는 디렉티브]

1. no-store 디렉티브 : 리퀘스트 또는 리스폰스에 기밀정보가 포함되어 있다는 의미를 나타냄

[● 캐시 기한이나 검증을 지정하는 디렉티브]

1. s-maxage 디렉티브 : max-age 디렉티브와 동일한데 다른 점은 여러 유저가 이용할 수 있는 공유 캐시 서버에만 적용된다는 점이다.(같은 유저에 반복해서 리스폰스를 반환하는 캐시 서버는 무효)
2. max-age 디렉티브 : 리퀘스트에서 사용한 경우 지정된 값보다 새로운 경우에는 캐시되었던 리소스를 받아들일 수 있다. 지정한 값이 0이면 캐시 서버는 리퀘스트를 항상 오리진 서버에 넘길 필요가 있다. 서버에서 사용되는 경우 캐시 서버가 유효성의 재확인을 하지 않고 리소스를 캐시에 보존해 두는 최대 시간을 나타낸다. HTTP/1.1 캐시 서버는 동시에 Expires 헤더 필드가 달린 경우에는 max-age 디렉티브의 지정을 우선하고 Expires 헤더 필드를 무시한다. HTTP/1.0 캐시 서버는 반대로 max-age 디렉티브가 무시된다.
3. min-fresh 디렉티브 : 캐시된 리소스가 적어도 지정된 시간은 최신 상태의 것을 반환하도록 캐시 서버에 요구한다. (지정된 시간 이상 유효한지)
4. max-stale 디렉티브 : 캐시된 리소스의 유효기간이 끝났더라도 받아들일 수 있음
5. only-if-cached 디렉티브 : 클라이언트는 캐시 서버에 대해서 목적한 리소스가 로컬 캐시에 있는 경우만 리스폰스를 반환하도록 요구한다.
6. must-revalidate 디렉티브 : 리스폰스의 캐시가 현재도 유효한지 아닌지의 여부를 오리진 서버에 조회를 요구한다.
7. proxy-revalidate 디렉티브 : 모든 캐시 서버에 대해서 이후의 리퀘스트로 해당 리스폰스를 반환할 때는 반드시 유효성 재확인을 하도록 요구한다.
8. no-transform 디렉티브 : 리퀘스트, 리스폰스의 어느 쪽에 있어서도 캐시가 엔티티 바디의 미디어 타입을 변경하지 않도록 지정한다. 그래서 캐시 서버 등에 의해서 이미지가 압축되는 것을 방지한다.

[● Cache-Control 확장]

1. cache-extension 토큰 : 이해할 수 있는 캐시 서버에 대해서만 의미가 있다.

2.Connection

Connection 헤더 필드는 다음의 두 가지 역할을 한다.

• 프록시에 더 이상 전송하지 않는 헤더 필드를 지정 : 예) Connection: 더이상 전송하지 않는 헤더 필드 명
• 지속적 접속 관리 : 예) Connection: Close -> 서버측에서 명시적으로 접속을 끊고 싶을 경우

HTTP/1.1 이전 버전의 HTTP에서는 지속적 접속이 기본이 아니였다. 그래서 이전 버전의 경우 지속적 접속이 하고 싶은 경우 Connection 필드에 Keep-Alive를 붙여서 리스폰스 하였다.

3.Date

HTTP 메시지를 생성한 날짜를 나타낸다.

4.Pragma

HTTP/1.1 보다 오래된 버전의 흔적으로 HTTP/1.0 와의 후방 호환성만을 위해 정의된 헤더 필드이다. 클라이언트의 리퀘스트에서만 사용 가능하고, 캐시된 리소스의 리스폰스를 원하지 않음을 모든 중간 서버에 알리기 위해 사용된다.

5.Trailer

메시지 바디 뒤에 기술되어 있는 헤더 필드를 미리 전달할 수 있다.

6.Transfer-Encoding

메시지 바디의 전송 코딩 형식을 지정하는 경우에 사용된다. (HTTP/1.1 에서는 청크 전송만 정의되어 있다.)

7.Upgrade

HTTP 및 다은 프로토콜의 새로운 버전이 통신에 이용되는 경우에 사용된다.

8.Via

클라이언트와 서버 간의 리퀘스트 혹은 리스폰스 메시지의 경로를 알기 위해서 사용된다. 프록시, 게이트웨이는 자신의 서버 정보를 Via 헤더 필드에 추가한 뒤에 메시지를 전송한다.

9.Warning HTTP/1.0 리스폰스 헤더가 HTTP/1.1에서 변경된 것으로 리스폰스에 관한 추가 정보를 전달한다.

6.4 리퀘스트 헤더 필드

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

• Accept : 유저 에이전트에 처리할 수 있는 미디어 타입과 미디어 타입의 상대적인 우선순위를 전달하기 위해 사용된다. 타입/서브타입으로 설정 (예. text/html, image/jpeg …), 우선순위를 붙이고 싶은 경우 세미콜론으로 구분하고, ‘q=’로 표시할 품질 지수를 더한다.
• Accept-Charset : 유저 에이전트에서 처리할 수 있는 문자셋으로 상대적인 우선순위를 전달하기 위해 사용된다. 또 한 번에 여러개를 지정할 수 있다.
• Accept-Encoding : 유저 에이전트에서 처리할 수 있는 콘텐츠 코딩과 콘텐츠 코딩의 상대적인 우선 순위를 전달하기 위해서 사용된다. (gzip, compress, deflate, identity) ‘*’ 애스터 리스크를 지정하면 와일드 카드로써 모든 인코팅 포맷을 가리킨다.
• Accept-Language : 유저 에이전트가 처리할 수 있는 자연어 세트와 상대적인 우선순위를 전달하기 위해 사용
• Authorization : 인증 정보를 전달하기 위해 사용된다. 서버에 인증을 받으려는 유저 에이전트는 상태 코드 401 리스폰스의 뒤에 리퀘스트에 Authorization 헤더 필드를 포함한다.
• Expect : 클라이언트가 서버에 특정 동작 요구를 전달한다.
• From : 유저의 메일 주소를 전달한다.
• Host : 리퀘스트한 리소스의 인터넷 호스트와 포트 번호를 전달한다. HTTP/1.1에서 유일한 필수 헤더 필드이다.(같은 IP주소에 복수의 도메인이 적용된 경우에 대비하기 위해 명확히 호스트명을 기재할 필요가 있다.)
• If-Match : 조건부 리퀘스트로 서버는 If-Match의 필드 값과 리소스의 ETag 값이 일치하는 경우에만 리퀘스트를 받아들일 수 있다.
• If-Modified-Since : 리소스 갱신 날짜가 필드 값보다 새롭지 않다면 리퀘스트를 받아들이겠다는 뜻을 전달한다.
• If-None-Match : If-Match 헤더 필드와는 반대로 동작한다.
• If-Range : 지정한 필드 값과 지정한 리소스의 ETag 값 혹은 날짜가 일치하면 Range 리퀘스트로서 처리하고 싶다는 것을 전달 한다. 일치하지 않는 경우 리소스 전체를 반환한다.
• If-Unmodified-Since : If-Modified-Since와 반대로 동작한다.
• Max-Forwards : TRACE or OPTIONS 메소드에 의한 리퀘스트시 전송해도 좋은 서버 수의 최대치를 10진수 정수로 지정한다. HTTP를 사용한 통신시 여러대의 서버를 경유해가는 경우가 있다. 이때 리스폰스가 되돌아 오지 않기 때문에 클라이언트쪽에서 알 수가 없어 이러한 문제를 해결하기 위해 사용된다.
• Proxy-Authorization : 인증에 필요한 클라이언트의 정보를 전달한다.
• Range : 리소스의 일부분만 취득하는 Range 리퀘스트를 할 때 지정 범위를 전달한다.
• Referer : 리퀘스트가 발생한 본래 리소스의 URI를 전달한다.
• TE : 리스폰스로 받을 수 있는 전송 코딩의 형식과 상대적인 우선순위를 전달한다.
• User-Agent : 리퀘스트를 생성한 브라우저와 유저 에이전트의 이름 등을 전달하기 위한 필드이다.

6.5 리스폰스 헤더 필드

• Accept-Ranges : Range 리퀘스트를 접수할 수 있는지 여부를 전달한다. 수신 가능한 경우엔 ‘bytes’, 수신 불가능한 경우에는 ‘none’
• Age : 얼마나 오래 전에 오리진 서버에서 리스폰스가 생성되었는지를 전달, 필드 값의 단위는 초이다.
• ETag : 엔티티 태그라고 불리면 리소스를 특정하기 위한 문자열을 전달한다. 서버는 리소스마다 ETag 값을 할당한다. ETag에는 강한 ETag(조금 다르더라도 반드시 값은 변화)와 약한 ETag(리소스가 같다는 것만을 나타냄) 값으로 구별되어 있다
• Location : 클라이언트가 Request-URI 이외의 리소스 액세스를 유도하는 경우 사용된다. Location 헤더 필드를 포함한 리스폰스를 받으면 강제로 리다이렉트 하는 곳의 리소스에 액세스를 시도한다.
• Proxy-Authenticate : 클라이언트와 프록시 사이에서 인증이 이루어지는 경우 인증요구를 클라이언트에 전달한다.
• Retry-After : 클라이언트가 일정 시간 후에 리퀘스트를 다시 시행해야 하는지 전달한다.
• Server : HTTP 서버의 소프트웨어를 전달한다.
• Vary : 캐시를 컨트롤하기 위해 사용된다. 오리진 서버로부터 Vary에 지정되었던 리스폰스를 받아들인 프록시 서버는 이후 캐시된 때 리퀘스트와 같은 Vary에 지정되어 있는 헤더 필드를 가진 리퀘스트에 대하여만 캐시를 반환할 수 있다.
• WWW-Authenticate : HTTP 액세스 인증에 사용되는데 리소슷에 적용할 수 있는 인증 스키마와 파라미터를 전달한다.

6.6 엔티티 헤더 필드

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

• Allow : Request-URI에 지정된 리소스가 제공하는 메소드의 일람을 전달한다. (예. Allow:GET, HEAD)
• Content-Encoding : 서버가 엔티티 바디에 대해서 실시한 콘텐츠 코딩 형식을 전달한다.
• Content-Language : 엔티티 바디에 사용된 자연어를 전달
• Content-Length : 엔티티 바디의 크기를 전달
• Content-Location : 메시지 바디에 대응하는 URI를 전달한다.
• Content-MD5 : 메시지 바디가 변경되지 않고 도착했는지 확인하기 위해 MD5 알고리즘에 의해 생성된 값을 전달한다.
• Content-Range : 범위를 지정해서 일부분만 리퀘스트하는 Range 리퀘스트에 대해 리스폰스를 할 때에 사용된다.
• Content-Type : 엔티티 바디에 포함되는 오브젝트의 미디어 타입을 전달한다.
• Expires : 리소스의 유효기한 날짜를 전달한다. 캐시서버가 이 헤더필드를 포함한 리소스 수신시 지정된 날짜까지 리스폰스의 복사본을 유지하고 리퀘스트에는 캐시로 응답한다.
• Last-Modified : 리소스가 마지막으로 갱신되었던 날짜 정보를 전달한다.

6.7 쿠키를 위한 헤더 필드

서버와 클라이언트 간의 상태를 관리하는 쿠키는 유저 식별과 상태 관리에 사용되고 있는 기능이다.

[쿠키의 사양서]

• 넷스케이프사에 의한 사양 : 쿠키를 고안한 넷스케이프 커뮤니케이션스 사의 사양
• RFC2109 : 현재 사용하지 않음
• RFC2965 : 거의 사용되지 않음
• RFC6265

Set-Cookie

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

Cookie

클라이언트가 HTTP의 상태 관리 지원을 원할 때 서버로부터 수신한 쿠키를 이후의 리퀘스트에 포함해서 전달한다.

6.8 그 이외의 헤더 필드

HTTP 헤더 필드는 독자적으로 확장할 수 있다. 다음은 자주 사용되는 헤더 필드이다.

• X-Frame-Option : 클릭 재킹 공격을 막는 것을 목적으로 하고 있다.(DENY-거부, SAMEORIGIN)
• X-XSS-Protection : XSS 대책으로 브라우저의 XSS 보호 기능을 제어하는 HTTP 리스폰스 헤더이다.
• DNT : 개인 정보 수집을 거부하는 의사를 나타내는 HTTP 리퀘스트 헤더이다.(0-트래킹동의, 1-트래킹거부)
• P3P : 웹 사이트 상의 프라이버시 정책에 P3P를 사용한 것