[HTTP_NETWORK] HTTP 헤더(Header)

업데이트: June 11, 2020

이번 시간에는 HTTP 헤더에 대해 알아보자

1. HTTP 메시지 헤더

HTTP 프로토콜의 리퀘스트와 리스폰스에는 반드시 메시지 헤더가 포함되어 있는데 HTTP 헤더에는 리퀘스트나 리스폰스를 처리하기 위한 정보가 들어 있다.

HTTP 헤더 필드의 구조는 다음과 같이 헤더 필드 명과 필드 값으로 구성되어 있고, 콜론으로 나뉘어져 있다

헤더 필드 명 : 필드 값

예를 들어 메시지 바디의 오브젝트 타입을 가리키는 Content-Type이라는 HTTP 헤더 필드는 다음과 같이 구성된다.

Content-Type:text/html

하나의 HTTP 헤더 필드가 여러 개의 필드 값을 가질 수도 있다.

Keep-Alive:timeout=15, max=100

HTTP 헤더 필드가 중복된 경우 사양으로 명확하게 정해져있지 않기 때문에 브라우저에 따라 다른 동작을 하게 된다. 어떤 브라우저는 최초의 헤더를 우선으로 처리하고 어떤 브라우저는 마지막 헤더 필드를 우선적으로 처리한다.

2. 헤더 필드의 종류

1) 일반적 헤더 필드

리퀘스트 메시지와 리스폰스 메시지 둘 다 사용되는 헤더

2) 리퀘스트 헤더 필드

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

3) 리스폰스 헤더 필드

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

4) 엔티티 헤더 필드

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

3. HTTP/1.1 헤더 필드 종류

1) 일반 헤더 필드

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

4) 엔티티 헤더 필드

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

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

HTTP에서 교환되는 헤더 필드는 RFC2616에 정의된 47종류만 있는 것은 아니다. 예를 들면 쿠키와 Set-Cookie 와 같이 그 외의 RFC에 정의되어 폭 넓게 사용되는 것도 있다.

1) End-to-end 헤더

리퀘스트나 리스폰스의 최종 수신자에게 전달. 캐시에서 구축된 리스폰스 중 보존되어야 하고 다시 전송되지 않으면 안되도록 구성되어 있음

2) Hop-by-hop 헤더

한 번 전송에 대해서만 유효하고 캐시와 프록시에 의해 전송되지 않는것도 있음.
HTTP/1.1과 그 이후에서 사용되는 Hop-by-hop 헤더는 Connection 헤더 필드에 열거해야 한다.

Connection, Keep-Alive, Proxy-Authenticate, Proxy-Authorization, Trailer, TE, Transfer-Encoding, Upgrade

위 8개 이외의 헤더 필드는 Hop-by-hop 헤더 필드이며 그 외 나머지는 모두 End-by-end 헤더에 분류된다.

5. HTTP/1.1 일반 헤더 필드

HTTP/1.1의 일반 헤더 필드에 대해 자세히 알아보자. 리퀘스트와 리스폰스 양쪽에 사용되는 헤더이다.

1) Cache-Control

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

Cache-Control: private, max-age=0, no-cache

- Cache Request 디렉티브

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

- Cache Response 디렉티브

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

Cache-control: public

public 디렉티브가 사용되는 경우 다른 유저에게도 돌려줄 수 있는 캐시를 해도 좋다는 것을 나타냄

Cache-control: private

private 디렉티브가 사용되는 경우 리스폰스는 특정 유저만을 대상으로 하고 있다는 것을 나타냄. 캐시 서버는 특정 유저를 위해 리소스를 캐시할 수 있지만, 다른 유저로부터 같은 리퀘스트가 와도 해당 캐시를 반환하지 않도록 함

Cache-control: no-cache

no-cache 디렉티브는 캐시로부터 오래된 리소스가 반환되는 것을 막기 위해 사용된다. 클라이언트의 리퀘스트로 no-cache 디렉티브가 사용된 경우 캐시된 리스폰스를 클라이언트가 받아들이지 않음을 나타낸다. 즉 중간 캐시 서버가 오리진 서버까지 리퀘스트를 전송해야 한다.

서버의 리스폰스에 no-cache 디렉티브가 사용된 경우 캐시 서버는 리소스를 저장할 수 없음. 오리진 서버는 캐시 서버가 이후의 리퀘스트에서 리소스의 유효성을 재확인하지 않고 해당 리스폰스를 사용하지 못하도록 함

Cache-control: no-cache=Location

서버의 리스폰스로 no-cache의 필드 값에 헤더 필드명이 지정된 경우는 지정된 헤더 필드만 캐시할 수 없음. 즉 지정되지 않은 필드는 캐시가 가능. 이 파라미터는 리스폰스 디렉티브만 사용할 수 있다.

Cache-control: no-store

no-store 디렉티브는 리퀘스트 혹은 리스폰스에 기밀 정보가 포함되어있음을 나타낸다. 따라서 캐시는 리퀘스트, 리스폰스의 일부를 로컬에 저장해서 안된도록 지정한다.

Cache-control: s-maxage=604800 (단위:초)

s-maxage 디렉티브는 max-age 디렉티브와 동일한데 여러 유저가 이용할 수 있는 공유 캐시 서버에만 적용된다는 점에 차이가 있다.

s-maxage 디렉티브가 사용되는 경우, Expires 헤더 필드의 max-age 디렉티브는 무시된다.

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

max-age 디렉티브가 사용되었다면 지정되었던 값보다 새로운 경우 캐시되었던 리소스를 받아들일 수 없다. 또한 지정된 값이 0이면 캐시 서버는 리퀘스트를 항상 오리진 서버에 넘길 필요가 있다.

서버의 리스폰스에서 max-age 디렉티브가 사용되면 캐시 서버가 유효성을 재확인하지 않고 리소스를 캐시에 보관해두는 최대 시간을 나타낸다.

HTTP/1.1 캐시 서버는 Expires 헤더 필드가 달린 경우 max-age 디렉티브 지정을 우선하고 Expire 헤더 필드는 무시한다. HTTP/1.0 캐시 서버는 반대로 max-age 디렉티브가 무시된다.

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

min-fresh 디렉티브가 사용된 경우 캐시된 리소스가 적어도 지정된 시간은 최신 상태의 것을 반환하도록 캐시 서버에 요구한다. 예를 들어 60초로 지정된 경우 60초 이내에 유효기한이 끝나는 리소스를 리스폰스로 반환하면 안된다.

Cache-control: max-stale=3600 (단위:초)

max-stale 디렉티브는 캐시된 리소스의 유효 기한이 끝났더라도 받아들일 수 있음을 의미한다. 값이 지정되어 있지 않은 경우는 시간이 아무리 지났더라도 리스폰스를 받아들인다. 값이 지정된 경우 유효기간이 지난 후로부터 지정 시간 내라면 받아들인다는 뜻을 서버에 전달한다.

Cache-control: only-if-cached

클라이언트는 캐시 서버에 대해서 목적한 리소스가 로컬 캐시에 있는 경우만 리스폰스를 반환하도록 요구한다. 즉 캐시 서버에서 리스폰스의 리로드와 유효성을 재확인하지 않도록 요구한다. 캐시 서버가 로컬 개시로부터 응답할 수 없는 경우 ‘504 Gateway Timeout’ 상태를 반환한다.

Cache-control: must-revalidate

리스폰스의 캐시가 현재도 유효한지 아닌지에 대한 여부 조회를 오리진 서버에 요구한다. 프록시가 오리진 서버에 도달할 수 없고, 리소스를 다시 요구할 수 없는 경우 캐시는 클라이언트에 504를 반환한다. must-revalidate가 사용되는 경우 리퀘스트에서 max-stale를 사용하고 있더라도 무시한다.

Cache-control: proxy-revalidate

모든 캐시 서버에 대해 이후의 리퀘스트로 해당 리스폰스를 반환하는 경우 반드시 유효성 재확인을 하도록 요구한다

Cache-control: no-transform

캐시가 엔티티 바디의 미디어 타입을 변경하지 않도록 지정한다. 이렇게 해서 캐시 서버 등에 의해 이미지가 압축되는 것을 방지한다.

2) Connection

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

프록시에 더 이상 전송하지 않는 헤더 필드를 지정하고, 지속적인 접속 관리를 하는 역할을 한다. 프록시 서버에 더이상 전송하지 않는 헤더(hop-by-hop)를 지정할 수 있다.

Connection : Close

HTTP/1.1에서는 지속적 접속이 디폴트로 되어 있다. 따라서 리퀘스트를 송신한 클라이언트는 접속이 계속 유지되면서 추가 리퀘스트를 송신하도록 하는데, 서버 측에서 명시적으로 연결을 끊고 싶은 경우 Close라고 지정한다.

Connection : Keep-Alive

하지만 HTTP/1.1 이전 버전에서는 지속적 접속이 디폴트가 아니었다. 따라서 지속적 접속을 하고 싶은 경우 Keep-Alive 라고 지정해야 한다.

3) Date

Date : Tue, 02 May 2020 02:12:12 GMT

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

4) Pragma

Pragma: no-cache

지정할 수 있는 형식은 no-cache 하나이다. HTTP/1.1 이전 버전에서 주로 사용되었으며 클라이언트는 캐시된 리소스의 리스폰스를 원하지 않음을 모든 중간서버에 알리기 위해 사용된다. HTTP/1.1 기준으로는 Cache-control: no-cache 에 해당되는데, 우리는 중간 서버의 HTTP 버전을 모두 알 수 없으므로 아래와 같이 두 개를 모두 보내는 경우도 있다.

Cache-control: no-cache
Pragma: no-cache

5) Trailer

Trailer 헤더 필드는 메시지 바디 뒤에 기술된 헤더 필드를 미리 전달할 수 있다. 이 헤더 필드는 HTTP/1.1에 구현된 청크 전송 인코딩을 사용하는 경우에 사용이 가능하다.

Trailer: Expires

...(메시지 바디)...

0
Expires: Tue, 22 May 2020 12:00:00 GMT

6) Transfer-Encoding

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

Transfer-Encoding: chunked

7) Upgrade

Upgrade 헤더 필드는 HTTP 및 다른 프로토콜의 새로운 버전이 통신에 이용되는 경우 사용된다.

Upgrade: TLS/1.0
Connection: Upgrade

Upgrade 헤더 필드에 의해 업그레이드 되는 대상은 클라이언트와 인접한 서버 사이뿐이기 때문에 Connection:Upgrade 도 지정할 필요가 있다.

8) Via

리퀘스트 혹은 리스폰스의 경로를 알기 위해 사용된다. 프록시 혹은 게이트웨이는 자신의 서버 정보를 Via 헤더 필드에 추가한 뒤 메시지를 전송한다. 메시지 추적과 리퀘스트 루프 회피 등에 사용되기 때문에 프록시를 경유하는 경우 반드시 부가해야 한다.

9) Warning

HTTP/1.0 리스폰스 헤더(Retry-After)가 HTTP/1.1에서 변경된 것으로 리스폰스에 관한 추가 정보를 전달한다. 기본적으로 캐시에 대한 문제 경고를 유저에게 전달한다.

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

경고 코드는 아래와 같다

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

6. 리퀘스트 헤더 필드

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

1) Accept

Accept: text/html, application/xhtml+xml, application/xml;q=0.9,*/*;q=0.8

유저 에이전트에 처리할 수 있는 미디어 타입과 우선순위를 전달하기 위해 사용된다. 미디어 타입 지정은 ‘타입/서브타입’의 형태로 한 번에 여러 번 설정할 수도 있다.

미디어 타입에 우선순위를 붙이고 싶은 경우 세미콜론으로 구분한 뒤, ‘q=값’ 으로 표시할 품질 지수를 선택한다. 품질 계수는 0~1 사이의 범위로 소수점 3자리까지 입력이 가능하며 1이 높은 쪽이다. 지정이 없는 경우 암묵적으로 ‘q=1.0’을 나타낸다.

2) Accept-Charset

Accept-Charset:iso-8859-5, unicode-1-1;q=0.8

유저 에이전트에서 처리할 수 있는 문자셋으로 문자셋의 상대적 우선순위를 전달하기 위해 사용된다. 또한 문자셋은 한번에 여러개를 지정할 수 있다. 해당 헤더 필드는 서버 구동형 네고시에이션에 이용된다.

3) Accept-Encoding

Accept-Encoding: gzip, deflate

유저 에이전트가 처리할 수 있는 콘텐츠 코딩과 우선순위를 전달하기 위해 사용된다.

gzip : 파일 압축 프로그램 gzip(GNU zip)에서 생성된 인코딩 포맷
compress : UNIX 파일 압출 프로그램 ‘compress’에 의해 만들어진 인코딩 포맷
deflate : Zlib 포맷과 deflate 압축 알고리즘에 의해 만들어진 포맷을 조합한 것
identity : 압축과 변형을 하지 않는 디폴트 인코딩 포맷

*(애스터리스크)를 지정하면 모든 인코딩 포맷을 가리킨다.

4) Accept-Language

Accept-Language: ko-kr, en-us;q=0.7, en;q=0.3

유저 에이전트가 처리할 수 있는 자연어 종류와 우선순위를 전달한다. 위 예는 한국어 리소스가 있는 경우 한국어로, 없는 경우 영어로 리스폰스를 받고싶다는 것을 나타낸다.

5) Authorization

Authorization: Basic dWVub3NlbqwjefiDfji==

유저 에이전트의 인증 정보를 전달하기 위해 사용된다.

6) Expect

Expect: 100-continue

클라이언트가 서버에 특정 동작 요구를 전달한다. 기대하는 요구에 서버가 응답하지 못해 에러가 발생하는 경우 417 Expectation Failed를 반환한다. HTTP/1.1 사양에서는 100-Continue만 정의되어 있다. 상태코드 100 리스폰스를 가진 클라이언트는 리퀘스트시 Expect:100-continue 를 지정해야 한다

7) From

From: 1q1w@github.io

유저 에이전트를 사용하고 있는 유저의 메일 주소를 전달한다. 기본적으로 검색 엔진 등의 에이전트 책임자에게 메일 주소를 나타내는 목적으로 사용된다. 에이전트에 따라 User-Agent 헤더 필드에 메일 주소를 포함하는 경우도 있다.

8) Host

Host: 1q1w.github.io

리퀘스트한 리소스의 인터넷 호스트와 포트 번호를 전달한다. Host 헤더 필드는 HTTP/1.1에서 유일한 필수 헤더 필드이다. Host 헤더가 존재하는 이유는 1대의 서버에서 복수의 도메인을 할당하는 가상 호스트 구조와 깊은 관련이 있다. 리퀘스트가 서버에 오면 호스트 명을 IP 주소로 해결해 리퀘스트가 처리되는데, 같은 IP 주소로 복수의 도메인이 적용되어 있는 경우 어떤 도메인에 대한 리퀘스트인지 알 수 없다. 따라서 Host 헤더 필드에 리퀘스트를 받을 호스트명을 명확히 해둘 필요가 있다.

9) If-Match

If-Match: "121212"

조건부 리퀘스트를 받은 서버는 지정된 조건에 맞는 경우에만 리퀘스트를 받게 된다. If-Match 헤더 필드는 서버 상의 리소스를 특정하기 위해 엔티티 태그(ETag) 값을 전달한다. 서버는 리소스의 ETag 값이 일치하는 경우에만 리퀘스트를 받아들일 수 있다. 일치하지 않는 경우 412 Precondition Faild를 반환한다.

If-Match 필드 값에 ‘*‘를 지정할 수도 있다. 이 때는 ETag에 상관없이 리소스가 존재하면 리퀘스트를 처리할 수 있다.

10) If-Modified-Since

If-Modified-Since: Thu, 12 Apr 2020 00:00:00 GMT

조건부 리퀘스트의 하나로 리소스가 갱신된 날짜가 필드 값보다 새롭다면 리퀘스트를 받아들이겠다는 뜻을 전달한다. 지정된 리소스가 갱신되지 않은 경우 304 Not Modified 리스폰스를 반환한다.

11) If-None-Match

If-Match 필드와 반대 역할을 한다. 헤더 필드에 지정된 값과 ETag의 값이 일치하지 않는 경우 리퀘스트를 받아들인다.

12) If-Range

지정한 필드 값과 지정한 리소스의 ETag값 혹은 날짜가 일치하면 Range 리퀘스트로 처리하고 싶다는 것을 전달한다. 일치하지 않는 경우 리소스 전체를 반환한다.

13) If-Unmodified-Since

If-Unmodified-Since: Thu, 03 Jul 2020 00:00:00 GMT

If-Modified-Since 헤더 필드와 반대로 동작한다. 지정된 리소스가 필드 값에 지정된 날짜 이후에 갱신되지 않은 경우에만 리퀘스트를 받아들이도록 한다. 지정된 날짜 이후 갱신된 경우 412 Precondition Failed 리스폰스를 반환한다.

14) Max-Forwards

Max-Forwards: 10

TRACE 혹은 OPTIONS 메소드에 의한 리퀘스트를 할 때 전송해도 좋은 서버 수의 최대치를 정수로 지정한다. 서버에서 다음 서버로 리퀘스트를 전송하는 경우 값을 1씩 빼서 다시 세트한다. 값이 0인 리퀘스트를 받은 경우 전송하지 않고 리스폰스를 반환한다.

HTTP 통신을 하는 경우 프록시 서버 등 여러 서버를 경유해 가는 경우가 있는데, 도중에 프록시 서버에서 리퀘스트 전송이 실패하면 클라이언트에 리스폰스가 돌아오지 않게 되기 때문에 알 수가 없다. 이러한 상황의 원인을 찾기 위해 활용되는 헤더 필드이다.

15) Proxy-Authorization

Proxy-Authorization: Basic WEJIjgkjef3

프록시 서버에서의 인증 요구를 받아들인 때에 필요한 클라이언트 정보를 전달한다. 클라이언트와 서버의 HTTP 액세스 인증과 비슷한데 다른 점은 클라이언트와 프록시 사이에 인증이 이루어진다는 점이다. 클라이언트와 서버의 경우 Authorization 헤더 필드와 같은 역할을 한다.

16) Range

Range: bytes=5001-1000

리소스의 일부분만 취득하는 Range 리퀘스트시 지정 범위를 전달한다. 위 예에서는 5001 바이트부터 10000 바이트까지 리소스를 요구한다. 서버가 리퀘스트를 처리할 수 있는 경우 206 Partial Content 리스폰스를 반환한다. Range 리퀘스트로 처리할 수 없는 경우 200 OK 리스폰스로 리소스 전체를 반환한다.

17) Referer

Referer : http://1q1w.github.io/index.html

리퀘스트가 발생한 본래 리소스의 URI를 전달한다. 기본적으로 Referer 헤더 필드는 보내져야 하지만 인터넷 주소창에 직접 URI를 입력항 경우, 또는 보안상 바람직하지 않다고 판단되면 보내지 않아도 된다.

18) TE

TE: gzip, deflate;q=0.5

리스폰스로 받을 수 있는 전송 코딩 형식과 우선순위를 전달한다. Accept-Encoding 헤더 필드와 비슷하지만 TE는 전송 코딩에 해당한다. TE 헤더 필드는 전송 코딩 지정 외에 Trailer를 동반하는 청크 전송 인코딩 형식을 지정하는 것이 가능하다. 이 경우 필드 값에 ‘trailers’라고 기록한다.

19) User-Agent

User-Agent: Mozila/5.0 (Windows NT 6.1) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.162 Safari/535.195

리퀘스트를 생성한 브라우저와 유저 에이전트의 이름 등을 전달한다.

7. 리스폰스 헤더 필드

서버 측에서 클라이언트 측으로 송신되는 리스폰스 메시지에 적용된 헤더로 리스폰스 부가 정보나 서버의 정보, 클라이언트에 부가 정보 요구 등을 전달한다.

1) Accept-Ranges

Accept-Ranges: bytes

서버가 리소스의 일부분만 지정해서 취득할 수 있는 Range 리퀘스트를 접수할 수 있는지 여부를 전달한다. 수신이 가능한 경우 ‘bytes’, 불가능한 경우 ‘none’라고 기록한다.

2) Age

Age: 600

오리진 서버에서 얼마나 오래 전에 리스폰스가 생성되었는지를 전달한다. 값의 단위는 초이다.

3) ETag

Etag: "82e2225492ce4787faf484321564egd12"

엔티티 태그라고 불리며 리소스를 특정하기 위한 문자열을 전달한다. 서버는 리소스마다 ETag 값을 할당한다. 리소스가 갱신되면 ETag도 갱신할 필요가 있다. ETag 값에 룰은 없으며 서버에 따라 다양한 값을 할당한다.

4) Location

Location: http://1q1w.github.io/index.html

리스폰스의 수신자에 대해 Request-URI 이외의 리소스 액세스를 유도하는 경우 사용된다. 기본적으로 ‘3xx: Redirection’ 리스폰스에 대해 리다이렉트 처의 URI를 기술한다. 대부분의 브라우저는 Location 헤더 필드를 포함한 리스폰스를 받으면 강제로 리다이렉트 하는 곳의 리소스에 액세스를 시도한다.

5) Proxy-Authenticate

Proxy-Authenticate: Basic realm="Usagidesign Auth"

프록시 서버에서의 인증 요구를 클라이언트에 전달한다. 클라이언트와 서버의 HTTP 액세스 인증과 비슷한데, 클라이언트와 프록시 사이에 인증이 이루어진다는 점이 다르다. 클라이언트와 서버의 경우 ‘WWW-Authrization’ 헤더 필드와 같은 역할을 한다.

6) Retry-After

Retry-After: 120

클라이언트가 일정 시간 후에 리퀘스트를 다시 시행해야 하는지를 전달한다. 주로 상태 코드 503 Service Unavailable 리스폰스나 3xx Redirect와 같이 사용된다.

7) Server

Server: Apache/2.2.17(Unix)

서버에 설치된 HTTp 서버의 소프트웨어를 전달한다. 버전이나 옵션에 대해서도 기재하는 경우가 있다.

8) Vary

Vary: Accept-Language

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

오리진 서버로부터 Vary에 지정된 리스폰스를 받아들인 프록시 서버는 이후 캐시된 때의 리퀘스트와 같은 Vary에 지정된 헤더 필드를 가진 리퀘스트에 대해서만 캐시를 반환할 수 있다. 같은 리소스에 대한 리퀘스트라도 Vary에 지정된 필드가 다른 경우 오리진 서버로부터 리소스를 취득할 필요가 있다.

9) WWW-Authenticate

WWW-Authenticate: Basic realm="Usagidesign Auth"

HTTP 액세스 인증에 사용되는데 Request-URI에 지정했던 리소스에 적용할 수 있는 인증 스키마와 파라미터를 나타내는 challenge를 전달한다.

8. 엔티티 헤더 필드

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

1) Allow

Allow: GET, HEAD

Request-URI에 지정된 리소스가 제공하는 메소드 종류를 전달한다. 서바가 받을 수 없는 메소드를 수신한 경우 405 Method Not Allowed 리스폰스와 함께 수신 가능한 메소드 종류를 기술한 Allow 헤더 필드를 반환한다.

2) Content-Encoding

Content-Encoding: gzip

서버가 엔티티 바디에 대해 실시한 콘텐츠 인코딩 형식을 전달한다. 콘텐츠 코딩은 엔티티 정보가 누락되지 않도록 압축할 것을 지시한다.

3) Content-Language

Content-Lauguage: en

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

4) Content-Length

Content-Length: 15000

엔티티 바디의 크기(단위는 bytes)를 전달한다. 엔티티 바디에 전송 코딩이 실시된 경우 해당 필드를 사용하면 안된다.

5) Content-Location

Content-Location: http://1q1w.github.io/index.html

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

6) Content-MD5

Content-MD5: WIJEIjfifjiWEJIFqjwieOJWGIOWE==

메시지 바디가 변경되지 않고 도착했는지 확인하기 위해 MD5 알고리즘에 의해 생성된 값을 전달한다. 유효성 확인을 위해 클라이언트 측에서 동일한 MD5 알고리즘을 실행한다. 서로 값을 비교하여 메시지 바디가 올바른지 여부를 알 수 있다. 이 방식으로는 우발적인 변경은 알 수 있지만 악의적인 변조는 검출할 수 없다.

7) Content-Range

Content-Range: 5001-10000/10000

범위를 지정해서 일부분만을 리퀘스트하는 Range 리퀘스트에 대해 리스폰스 할 때 사용된다. 리스폰스로 보낸 엔티티가 어느 부분에 해당하는지를 전달하고, 현재 보내는 범위와 전체 사이즈를 기록한다.

8) Content-Type

Content-Type: text/html; charset=UTF-8

엔티티 바디에 포함되는 오브젝트의 미디어 타입을 전달한다. Accept 헤더 필드와 같이 ‘타입/서브타입’으로 기록한다.

9) Expires

Expires: Wed, 04 Jul 2020 00:00:00 GMT

리소스의 유효 기한 날짜를 전달한다. 캐시 서버가 해당 필드를 포함한 리소스를 수신한 경우 필드 값으로 지정된 날짜까지 리스폰스의 복사본을 유지하고 리퀘스트에 캐시로 응답한다. 지정된 날짜가 지난 경우 리퀘스트가 오면 오리진 서버에 리소스를 얻으러 간다. 오리진 서버가 캐시 서버에 캐시되는 것을 원하지 않는 경우 Date 헤더 필드와 값과 같은 날짜로 지정하는 것이 바람직하다.

10) Last-Modified

Last-Modified: Wed, 10 May 2020 00:00:00 GMT

리소스가 마지막으로 갱신된 날짜 정보를 전달한다.

9. 쿠키를 위한 헤더 필드

서버와 클라이언트의 상태를 관리하는 쿠키는 HTTP/1.1 사양에 포함되지는 않았지만 웹 사이트에서 널리 사용되고 있다. 쿠키는 유저 식별과 상태 관리에 사용되는 기능이다. 웹 사이트가 유저 상태를 관리하기 위해 웹 브라우저를 통해 유저의 컴퓨터 상에 일시적으로 데이터를 기록해두고, 다음에 그 유저가 웹 사이트에 액세스하면 지난번에 발행한 쿠키를 송신받을 수 있다.

쿠키가 호출되었을 때는 쿠키의 유효 기한과 송신지의 도메인, 경로, 프로토콜 등을 체크하는 것이 가능하기 때문에, 적절하게 발행된 쿠키는 다른 웹 사이트의 공격에 의해 데이터가 도난당하는 일은 없다.

쿠키와 관련된 헤더 필드는 다음과 같은 것이 사용되고 있다.

Set-Cookie: status-enable; expires=Tue, 05, Jul 2020 00:00:00 GMT; =>path=/;domain=.github.io;

속성	설명
NAME=VALUE	쿠키에 부여된 이름과 값 (필수)
Expires=DATE	쿠키 유효 기한 (지정되지 않은 경우 브라우저 종료시까지)
Path=PATH	쿠키 적용 대상이 되는 서버 상의 디렉토리 (지정하지 않은 경우 도큐먼트와 같은 디렉토리)
Domain=도메인 명	쿠키 적용 대상이 되는 도메인 명 (지정하지 않은 경우 쿠키를 생성한 서버의 도메인)
Secure	HTTPS로 통신하고 있는 경우에만 쿠키를 송신
HttpOnly	쿠키를 JavaScript에서 액세스하지 못하도록 제한

Expires : 쿠키의 유효기한을 지정한다. Expires가 생략된 경우 브라우저 종료 시까지만 쿠키가 유효하게 된다.
Domain : 도메인 속성에 의해 지정된 명은 후방 일치가 된다. 따라서 명시적으로 여러 도메인에 대해 쿠키를 송출하는 경우를 제외하고 domain 속성은 지정하지 않는 것이 안전하다
Secure : 웹 페이지가 HTTPS에서 열렸을 때만 쿠키를 반송한다. 해당 속성이 생략되면 HTTP, HTTPS 모두 쿠키를 반송한다.
HttpOnly : 자바스크립트에서 쿠키를 취득하지 못하도록 하는 쿠키의 확장 기능이다. 해당 속성으로 부여된 쿠키는 ‘document.cookie’ 에서 읽어들일 수 없게 된다. 따라서 자바스크립트를 통해 쿠키를 훔치는 것이 불가능하다.

Cookie: status=enable

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

10. 그 외의 헤더 필드

1) X-frame-Option

X-frame-Option: DENY

다른 웹 사이트의 프레임에서 표시를 제어하는 HTTP 리스폰스 헤더로, 클릭 재킹이라는 공격을 막는 것을 목적으로 한다. 지정할 수 있는 값은 아래와 같다.

DENY: 거부
SAMEORIGIN: Top-Level-browsing-context가 일치한 경우에만 허가

해당 옵션은 모든 웹 서버에서 설정해두는 것이 바람직하다.

2) X-XXS-Protection

X-XXS-Protection: 1

크로스 사이트 스크립팅(XXS) 방안으로 브라우저의 XXS 보호 기능을 제허하는 HTTP 리스폰스 헤더이다. 지정할 수 있는 값은 아래와 같다.

0 : XXS 필더를 무효로 한다.
1 : XXS 필터를 유효로 한다.

3) DNT

DNT: 1

Do Not Track 라는 뜻이며 개인 정보 수집을 거부하는 의사를 나타내는 헤더이다. 타깃 광고 등에 이용되는 트래킹의 거부 의사를 나타내기 위한 방법 중 하나이다.

0 : 트래킹 동의
1 : 트래킹 거부

4) P3P

P3P: CP="CAO DSP LAW CUIE IDJb SILa ..."

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

Twitter Facebook LinkedIn

bonobono