HTTP Header

HTTP 메세지 헤더

HTTP 메세지는 크게 메세지 헤더, 개행문자(CRLF), 메세지 바디로 구성

HTTP 프로토콜의 리퀘스트와 리스폰스에는 반드시 메세지 헤더가 포함되어 있는데, 메세지 헤더에는 클라이언트나 서버가 리퀘스트나 리스폰스를 처리하기 위한 정보가 들어있음
-> 메세지 바디에는 사용자와 리소스를 필요로 하는 정보가 있음

리퀘스트 HTTP 메세지

메세지 헤더는 리퀘스트 라인(메소드,URI,HTTP 버젼), 리퀘스트 헤더 필드, 일반 헤더 필드, 엔티티 헤더 필드로 구성되어 있음
-> 요청 라인을 메세지 헤더 안이 아닌, 밖에 있는 것으로 보기도 함
-> 3가지 헤더 필드를 합쳐서 HTTP 헤더 필드라고 함

1. 요청 라인(Request Line): HTTP 메시지의 첫 번째 라인에 포함되며, 요청 방식(GET, POST, PUT 등), 요청 URL, HTTP 버전을 포함

2. 요청 헤더(Request Header): HTTP 메시지의 두 번째 라인부터 시작하며, 요청과 관련된 추가 정보를 포함. 예를 들어, 요청자의 사용자 에이전트, 요청자의 언어, 요청자의 인증 정보 등이 포함될 수 있음

3. 메시지 바디(Message Body): 요청 또는 응답에 포함되는 실제 데이터를 포함. 예를 들어, HTML 페이지, 이미지, 오디오 파일 등이 포함될 수 있음.주어진 HTTP 메시지에 따라 메시지 바디가 필요 없을 수도 있다

GET /index.html HTTP/1.1
Host: www.example.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:96.0) Gecko/20100101 Firefox/96.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Connection: keep-alive
Referer: https://www.example.com/

리스폰스 HTTP 메세지

리퀘스트 메세지의 리퀘스트 라인, 리퀘스트 헤더 필드 위치에 상태 라인, 리스폰스 헤더 필드가 위치할시 리스폰스 HTTP 메세지

HTTP/1.1 200 OK
Date: Sun, 31 Jan 2022 12:34:56 GMT
Server: Apache/2.4.18 (Ubuntu)
Last-Modified: Sat, 30 Jan 2022 10:15:00 GMT
ETag: "5f23a7-1b3-591e98c234640"
Accept-Ranges: bytes
Content-Length: 439
Content-Type: text/html

---

HTTP 헤더 필드

HTTP 메세지를 구성하는 요소 중 하나로 리퀘스트뿐 아니라 리퀘스트에도 사용되며, 부가적으로 중요한 정보를 전달하는 역할 담당
-> ex) 메세지 바디의 크기, 사용하고 있는 언어, 인증 정보

헤더 필드 명 : 필드 값으로 구성되어 있음

ex)

Content-Type:text/html

하나의 필드에 여러 값을 적을 수도 있음
Keep-Alive:timeout=15, max=100

HTTP 헤더 필드 중 같은 이름의 헤더가 2개가 중복되는 경우 브라우저마다 처리 방식이 조금씩 다르지만 보통 선행의 헤더가 먼저 처리가 되거나 마지막 헤더가 먼저 처리가 됨

종류

1. 일반적 헤더 필드(General Header Field), 공통 헤더
   리퀘스트와 리스폰스 메세지 둘다 사용되는 헤더

2. 리퀘스트 헤더 필드(Request Header Fields)
   클라이언트 측에서 서버 측으로 송신된 리퀘스트 메세지에 사용되는 헤더
   (클라이언트 정보, 리스폰스의 콘텐츠에 관한 우선 순위 등)

3. 리스폰스 헤더 필드(Response Header Fields)
   서버 측에서 클라이언트 측으로 송신한 리스폰스 메세지에 사용되는 헤더
   (리스폰스 및 서버의 정보, 클라이언트의 추가 정보 요구)

4. 엔티티 헤더 필드(Entity Header Fields)
   리퀘스트 메세지와 리스폰스 메세지에 포함된 엔티티에 사용되는 헤더로 콘텐츠 갱신 시간 등의 엔티티에 관한 정보 부가

HTTP 헤더 필드가 RFC2616에서 정의된 47종류만 있는 것은 아님
-> 쿠키와 set-cookie, Content-Disposition와 같이 비표준 헤더 필드는 RFC4229 HTTP Header Field Registration에 정의

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

1. End-to-end header
   요청과 응답을 서버와 클라이언트 사이에서 주고 받을 때, 경로상의 다른 미들웨어 또는 네트워크 구성 요소에서 수정되지 않는 것을 보장하는 헤더

2. Hop-by-hop header
   Hop-by-hop header는 HTTP 헤더로서 요청이나 응답이 전송되는 경로상의 미들웨어에서 처리되어야 하는 정보를 나타내며, 전송 경로상에서 수정될 수 있음
   이는 Connection 헤더 필드에 열거해야 함

Hop-by-hop 헤더 종류

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

위 8개 헤더 필드 외에는 모두 End-to-End 헤더에 분류

---

HTTP/1.1 일반 헤더 필드

Cache-Control

Cache-Control 헤더는 디렉티브로 불리는 명령을 사용하여 캐싱 동작을 지정

지정된 디렉티브는 파라미터가 있는 것도 있고, 없는 것도 있으며, 다중의 디렉티브가 사용될 때에는 콤마로 구분
-> 디렉티브는 리퀘스트와 리스폰스를 기준으로 나눠짐

캐시 리퀘스트 디렉티브

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

캐시 리스폰스 디렉티브

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

---

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

1. public 디렉티브

Cache-control : public

응답이 캐싱 가능함을 의미하는 디렉티브

2. private 디렉티브

Cache-control : private

리스폰스가 특정 유저만을 대상으로 하고 있음을 나타냄
-> 즉 특정 유저를 위해서 리소스를 캐시할 수 있지만, 다른 유저로 부터 같은 리퀘스트가 온다 하더라도 그 캐시를 반환하지 않도록 함

3. no-cache 디렉티브

Cache-control : no-cache

캐시로부터 오래된 리소스가 반환되는 것을 막기 위해 사용됨

클라이언트의 리퀘스트로 no-cache 디렉티브가 사용된 경우, 캐시된 리스폰스를 클라이언트가 받아들이지 않음을 의미
-> 즉 중간 캐시 서버가 오리진 서버까지 리퀘스트를 전송해야 함

서버에 리스폰스에 no-cache 디렉티브가 사용된 경우, 캐시 서버는 리소스를 저장할 수 없음

특정 헤더 필드만 지정할 수도 있음

Cache-Control: no-cache = Location

위 처럼 지정된 헤더 필드 이외에는 캐시를 하는 것이 가능

---

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

1. no-store 디렉티브

Cache-Control : no-store

위 경우 리퀘스트나 리스폰스에 기밀 정보가 포함되어 있음을 나타냄
-> 따라서 캐시는 리퀘스트, 리스폰스의 일부분을 로컬 스토리지에 보존해서는 안되도록 지정한 것

---

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

1. s-maxage 디렉티브

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

max-age 디렉티브와 동일한데 다른 점은 여러 유저가 이용할 수 있는 공유 캐시 서버에만 적용된 다는 것
-> 즉 같은 유저에 반복해서 리스폰스를 반환하는 캐시 서버는 무효한 디렉티브

위 디렉티브 사용시 Expires 헤더 필드와, max-age 헤더 필드는 무시됨

2. max-age 디렉티브

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

클라이언트의 리퀘스트에서 "max-age" 디렉티브가 사용된 경우, 클라이언트는 캐시된 응답이 "max-age" 값으로 정의된 지정된 시간보다 새로운 것이라면 서버에서 캐시된 응답을 반환하도록 요청하는 것
-> "max-age" 값은 음수가 아닌 정수로, 응답이 새로운 것으로 간주될 수 있는 초 단위의 시간을 나타냄. 응답이 "max-age" 값보다 오래된 경우, 클라이언트는 서버에서의 새로운 응답을 원하며, 캐시된 응답은 원하지 않음

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

HTTP/1.1 캐시 서버는 동시에 Expires 헤더 필드가 달린 경우엔 max-age 디렉티브의 지정을 우선으로 하지만 HTTP/1.0은 반대

3. min-fresh 디렉티브

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

캐시된 리소스가 적어도 지정된 시간 만큼은 최신 상태인 것을 반환하도록 캐시 서버에 요구
-> 예를 들면, 60초로 지정되어 있는 경우에는 60초 이내에 유효 기한이 끝나는 리소스를 반환하면 안된다는 의미

---

max-stale 디렉티브

Cache-Control : max-stale = 3600

캐시된 리소스의 유효 기간이 끝났더라도 받아 들일 수 있음을 나타냄
-> 값이 지정 안되었다면 아무리 시간이 경과했더라도 리스폰스를 받아드림

only-if-cached 디렉티브

Cache-Control : only-if-cached

클라이언트가 캐시 서버에 대해서 목적한 리소스가 로컬 캐시에 있는 경우만 리스폰스를 반환하도록 요구
-> 즉 캐시 서버에서 리스폰스의 리로드와 유효성을 재확인 하지 않도록 요구

must-revalidate 디렉티브

Cache-Control : must-revalidate

위 디렉티브 사용시 리스폰스의 캐시가 현재도 유효한지 아닌지 여부를 오리진 서버에 조회를 요구
-> 프록시가 오리진 서버에 도달할 수 없고, 리소스를 다시 요구할 수 없을때만 504를 반환

max-stale 디렉티브보다 우선됨

proxy-revalidate 디렉티브

Cache-Control : proxy-revalidate

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

no-transform 디렉티브

Cache-Control : no-transform

리퀘스트와 리스폰스의 어느 쪽에 있어서도 캐시가 엔티티 바디의 미디어 타입을 변경하지 않도록 지정

cache-extension 토큰

Cache-Control : private, community="UCI"

cache-extension 토큰을 사용해 디렉터리를 확장 가능

---

Connection 헤더 필드

2가지 역할을 함

1. 프록시에 더 이상 전송하지 않는 헤더 필드 지정
2. 지속적 접속 관리

1
ex)

GET /HTTP /1.1
Upgrade : HTTP/ 1.1
Connection: Upgrade

위 경우 Connection 헤더에 의해
GET /HTTP / 1.1 이 전송됨

리퀘스트 혹은 리스폰스에서 Connection 헤더 필드를 사용하며, 프록시 서버에 더 이상 전송하지 않는 헤더필드 (hop-by-hop 헤더) 를 지정할 수 있음

2

HTTP/1.1에서는 지속적 접속이 Default 로 되어 있음
-> 따라서 리퀘스트를 송신했던 클라이언트는 접속이 계속 유지 되면서 추가 리퀘스트를 보낼 수 있음
-> 만약 서버에서 명시적으로 연결을 끊는다면 Connection 헤더 필드를 close로 지정해야 함

Connection : Close

HTTP 1.1 이전에는 지속적 접속이 디폴트가 아니였어서 지속적 접속을 하고 싶다면 Keep-Alive를 지정해야 했음

---

Date 헤더 필드

HTTP 메세지가 생성된 날짜를 나타냄

Date: Tue, 03 Jul 2012 04:40:59 GMT

---

Pragma

HTTP/1.1보다 오래된 버젼의 흔적으로 HTTP/1.0의 후방 호환성을 위해 정의되어 있는 헤더 필드

Pragma : no-cache

이는 일반 헤더 필드지만 클라이언트의 리퀘스트에만 사용하며 클라이언트는 캐시된 리소스의 리스폰스를 원하지 않음을 모든 중간서버에 알리기 위해 사용

중간 서버가 모두 HTTP/1.1을 기준으로 구성되었다면 캐시 동작은 Cache-Control: no-cache를 사용하는 것이 바람직하지만, 중간 서버의 버전을 모두 파악후에 리퀘스트를 보내는 일은 현실적으로 없어서 같이 사용

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

---

Trailer

메세지 바디의 뒤에 기술되어 있는 헤더 필드를 미리 전달할 수 있게 해주는 헤더
-> HTTP/1.1이 구현되어있는 청크 전송 인코딩을 사용하는 경우에만 가능

---

Transfer-Encoding

메세지 바디의 전송 코딩 형식을 지정하는 경우에 사용됨
-> HTTP/1.1에서 전송 코딩 형식으로 청크 전송만이 정의되어 있음

POST /example HTTP/1.1
Host: www.example.com
Transfer-Encoding: chunked

4
Wiki
5
pedia
e
 in

0

chunked 데이터는 여러 chunk로 분할되고 각 chunk는 16진수 형식의 크기로 앞에 나오며 마지막 chunk는 크기가 0인 chunk로 표시

Chunked encoding은 HTTP 프로토콜에서 데이터를 전송하는 방식
-> 데이터를 여러 개의 청크(chunk)로 분할하여 전송

---

Upgrade

HTTP 및 다른 프로토콜의 새로운 버전이 통신에 이용되는 경우 사용
-> 지정하는 대상이 전혀 다른 통신 프로토콜이라 하더라도 문제 X

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

HTTP/ 1.1 10.1 Switching Protocols
Upgrade : TLS/1.0, HTTP / 1.1
Connection : Upgrade

Via

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

Warning

보통 리스폰스에 관한 추가 정보를 전달
-> 캐시에 관한 문제의 경고를 유저에게 전달

HTTP/1.1 199 Warning
Warning: 199 Miscellaneous warning
Date: Mon, 03 Feb 2020 12:34:56 GMT

---

리퀘스트 헤더 필드

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

Accept

클라이언트가 처리할 수 있는 미디어 타입과, 미디어 타입의 상대적인 우선 순위를 전달하기 위해 사용

Accept: image/png, text/html

만약 브라우저가 png 이미지를 표시하지 못하는 경우에는 Accept에 image/png를 지정하지 않고, 처리 가능한 image/gif나 image/jpeg를 지정

우선 순위를 붙이고 싶을 경우 세미 콜론으로 구분하고 "q="로 품질 지수 더함
-> 0~1사이며 클수록 품질이 좋음

Accept-CharSet

클라이언트에서 처리할 수 있는 문자셋을 지정하거나, 우선순위를 지정할 때 사용

Accept-Encoding

클라이언트가 처리할 수 있는 콘텐츠 코딩과 콘텐츠 코딩의 우선 순위를 전달하기 위해 사용

Accept-Encoding : gzip, deflate

Accept-Lanaguage

클라이언트가 처리할 수 있는 자연어의 세트와 자연의 세트의 상대적 우선 순위를 전달하기 위해 사용

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

---

Authorization

클라이언트의 인증정보(크리덴셜 값)을 전달하기 위해 사용
-> 만약 인증이 필요한데 지정하지 않은 경우 401 Unauthorized

공유 캐시가 Authorization 헤더 필드를 포함하는 리퀘스트를 받은 경우는 조금 다르게 동작

Except

클라이언트가 서버에 특정 동작을 요구
-> 기대하고 있는 요구에 서버가 응답하지 못해서 에러가 발생하는 경우 상태 코드 417 Exception Failed를 반환

From

클라이언트가 사용하고 있는 유저의 메일 주소를 전달
-> 보통 검색 엔진 등의 에이전트 책임자에게 연락처 메일 주소를 나타내는 목적으로 사용

Host

리퀘스트한 리소스의 인터넷 호스트와 포트 번호를 전달
->이는 유일한 필수 헤더 필드

Host : www.hackr.jp

Host 헤더 필드가 존재하는 이유는 1대의 서버에서 복수의 도메인을 할당할 수 있는 가상 호스트의 구조와 깊은 관련이 있음
-> 리퀘스트가 서버에 오면 호스트 명을 IP 주소로 해결해 리퀘스트가 처리되는데, 이때 같은 IP 주소로 복수의 도메인이 적용되어 있다하면 어느 도메인에 대한 리퀘스트인지 알 수가 없음
-> 따라서 Host 헤더 필드에 리퀘스트를 받을 호스트명을 명확하게 해둘 필요가 있음

---

If-xxx

If-xxx 라는 서식의 리퀘스트 헤더 필드는 조건부 리퀘스트라고 부름
-> 조건부 리퀘스트를 받은 서버는 지정된 조건에 맞는 경우에만 리퀘스트를 받음

If-Match = "123456"

If-Match는 서버상의 리소스를 특정하기 위해 엔티티 태그(Etag) 값을 전달
-> If-Match의 필드 값과 ETag 값이 일치한 경우에만 리퀘스트를 받아드림

If-Modified-Since는 필드 값에 지정된 날짜 이후에 갱신된 리소스라면 리퀘스트를 받아드린다는 의미의 헤더

If-None-Match 헤더 필드는 If-Match 헤더 필드와 반대로 동작
-> 헤더에 지정된 엔티티 태그 값이 지정된 엔티티 태그 값과 일치하지 않으면 리퀘스트를 받아들이겠다는 뜻

예를들어 서버에서 Sample.html이라는 파일을 가지고 있지 않을 시

PUT /sample.html
If-None-Match : *

위 경우 파일을 가지고 있지 않으므로 ETag 값이 존재하지 않아 리퀘스트를 받아들임

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

If-Unmodified-Since 필드는 지정된 리소스가 필드 값에 지정된 날짜 이후에 갱신되지 않은 경우만 리퀘스트를 받아들이도록 전달

---

Max-Forwards

TRACE 혹은 OPTIONS 메소드에 의해 리퀘스트를 할 때에 전송해도 좋은 서버 수의 최대치를 10진수 정수로 지정
-> 서버가 다음 서버에 리퀘스트를 전송할때 Max-Forwards 값에서 1을 빼서 다시 세트
-> 통신 중 프록시 서버에서 무언가의 원인으로 리퀘스트 전송이 실패하게 되면 클라이언트에는 리스폰스가 되돌아 오지 않음
-> 이러한 문제가 발생한 경우의 원인 조사를 위해 Max-Forwards 헤더 필드가 활용 됨

필드 값이 0이 되었던 서버가 리스폰스를 하기 때문에 그 서버까지의 상황을 알수 있음
-> 예를 들어 목표로 했던 서버에 도착하지 않고 중간 프록시 서버에서 어떠한 원인으로 인해 리퀘스트가 루프하는 경우

Proxy-Authorization

프록시 서버에서의 인증 요구를 받아들일 때에 인증에 필요한 클라이언트 정보를 전달

클라이언트와 프록시 사이에 인증이 이루어 진다는 것
-> 클라이언트와 서버 사이의 경우 Authorization 헤더 필드와 같은 역할

---

Range

Range : bytes = 5001-10000

리소스의 일부분만 취득하는 Range 리퀘스트를 할때 지정 범위를 전달

Referer

리퀘스트가 발생한 본래 리소스의 URI를 전달
-> 기본적으론 Referer 헤더 필드는 보내져야 하지만, 브라우저 주소창에 직접 URI를 입력한 경우와 보안상 바람직하지 않다고 판단도 경우에는 보내지 않아도 괜찮음

TE

리스폰스로 받을 수 있는 전송 코딩의 형식과 상대적인 우선 순위 전달

User-Agent

리퀘스트를 생성한 브라우저와 유저 에이전트의 이름 등을 전달하기 위한 필드

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.82 Safari/537.36

---

리스폰스 헤더 필드

리스폰스 메세지에 적용되는 헤더로, 리스폰스의 부가 정보, 클라이언트에 부가 정보 요구 등을 나타냄

Accept-Ranges

서버가 리소스의 일부분만 지정해서 취득할 수 있는 Range 리퀘스트를 접수할 수 있는지 여부를 나타냄
-> 수신 가능한 경우엔 bytes, 불가한 경우에는 none이라고 기록

Age

얼마나 오래전에 오리진 서버에서 리스폰스가 생성되었는지 전달(단위 : 초)
-> 만약 리스폰스한 서버가 캐시 서버라면, 캐시된 리스폰스가 다시 실증되었던 때부터 검증한 시간이 됨

ETag

서버는 리소스 마다 ETag 값을 할당하게 되어있음
-> ETag 헤더 필드는 엔티티 태그라고 불리며 리소스를 특정하기 위한 문자열이 포함되어 있음

리소스가 갱신되면 ETag 값도 갱신한 필요가 있으며, 문자엔 특별히 룰이 정해져 있지 않음

Location

리스폰스 수신자(클라이언트)에 대해 Request-URI 이외의 리소스 엑세스를 유도하는 경우
-> Location 헤더 필드를 포함한 리스폰스를 받으면 강제로 리다이렉트 하는 곳의 리소스 엑세스를 시도

Proxy-Authenticate

프록시 서버에서의 인증 요구를 클라이언트에게 전달할 때 사용

Retry-After

클라이언트가 일정 시간 후에 리퀘스트를 다시 실행하라고 전달할때 사용

Server

서버에 설치되어 있는 HTTP 서버의 소프트웨어를 전달할때 사용

Server : Apache/2.26(Unix) PHP/5.2.5

Vary

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

Vary : Accept-Language

위 헤더의 의미
-> 오리진 서버가 프록시 서버에게 그 캐시는 Accept-Langauge가 같은 리퀘스트에서만 사용해야 해!

WWW-Authenticate

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

---

엔티티 헤더 필드

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

Allow

Request-URI에 지정된 리소스가 제공하는 메소드를 전달함

Allow : GET, HEAD

위 경우 우리 서버에서 사용 가능한 메서드는 GET과 HEAD라는 뜻

Content-Encoding

Content-Encoding:gzip

서버가 엔티티 바디에 대해서 실시한 콘텐츠 코딩 형식을 전달

4가지 콘텐츠 코딩 형식이 사용됨
-> Gzip, Compress, Deflate, identity

Content-Language

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

Content-Length

엔티티 바디의 크기 전달
-> 엔티티 바디에 전송 코딩이 적용도 경우엔 Content-Length 헤더 필드를 사용하면 안됨

Content-Location

메세지 바디에 대응하는 URI를 전달할때 사용
-> Location 헤더 필드와 다르게 메세지 바디로 반환된 리소스의 URI를 전달

Content-MD5

메세지 바디가 변경되지 않고 도착했는지 확인하기 위해 MD5 알고리즘에 생성된 값을 전달
-> 메세지 바디에 MD5 알고리즘을 적용해서 얻은 128비트 바이너리 값에, Base64로 인코딩한 결과를 필드 값에 기록(헤더에는 바이너리 값을 기록하는 것이 불가하여 Base64로 인코딩)
-> 유효성 확인을 위해 클라이언트 측에서 메세지 바디에 같은 MD5 알고리즘을 실행
-> 이렇게 해서 도출한 값과 필드 값을 비교하여 메세지 바디가 올바른지 여부 판단

위 방식을 통해 우발적으로 콘텐츠가 변경되어 버린 사실은 알수 있지만 악의적으로 가진 변조를 검출할수는 없음
-> 콘텐츠를 변조하면 Content-MD5 또한 재계산해서 변조하는 것이 가능하기 때문

Content-Range

범위를 지정해서 일부분만을 리퀘스트하는 Range 리퀘스트에 대해서 리스폰스를 할때 사용됨

Content-Type

엔티티 바디에 포함되는 오브젝트의 미디어 타입을 전달
-> 필드 값은 타입/서브 타입으로 기록 됨

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

Expires

유효 기한 날짜를 전달할때 사용하는 헤더
-> 캐시 서버가 Expires 헤더 필드를 포함한 리소스를 수신한 경우, 필드 값으로 지정된 날짜까지 리스폰스의 복사본을 유지하고 리퀘스트에 캐시로 응답
-> 지정 날짜가 지난 후에는 오리진 서버에 리소스를 얻으러 감

오리진 서버가 캐시 서버에 캐시되는 것을 원하지 않을 경우 Date 헤더 필드와, Expires 필드 값을 같은 날짜로 해두는 것이 바람직

Last-Modified

리소스가 마지막으로 갱신되었떤 날짜 정보를 전달

---

쿠키를 위한 헤더 필드

쿠키는 유저 식별과 상태 관리에 사용되는 기능으로 서버와 클라이언트간에 상태를 관리

Set-Cookie(리스폰스)

Set-Cookie: status-enable; expires=Tue, 05 Jul 2011 07:26:31 GMT;
=> path=/; domain=.hack.jp;

expires 속성으로 브라우저가 쿠키를 송출할 수 있는 유효기간 지정

path 속성으로 쿠키를 송출하는 범위를 특정 디렉토리에 한정

secure 속성은 웹 페이지가 HTTPS에서 열렸을 때에만 쿠키 송출을 제한하기 위해 지정

HttpOnly 속성은 자바 스크립트를 경유해서 쿠키를 취득하지 못하도록 하는 쿠키의 확장 기능

Cookie(리퀘스트)

Cookie: status=enable

Cookie 헤더 필드는 클라이언트가 HTTP의 상태 관리 자원을 원할 때 서버로부터 수신한 쿠키를 이후의 리퀘스트에 포함해서 전달

---

그 외의 헤더 필드

• X-Frame-Option
• X-XSS-Protection
• DNT
• P3P

X-Frame-Option

다른 웹 사이트의 프레임에서 표시를 제어하는 HTTP 리스폰스 헤더
-> 클릭 재킹이라는 공격을 막는 것을 목적으로 함

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

X-XSS-Protection

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

0 : XSS 필터를 무효로 한다

1: XSS 필터를 유효로 한다

DNT(Do Not Track)

개인 정보 수집을 거부하는 의사를 나타내는 HTTP 리퀘스트 헤더

0은 트래킹 동의, 1은 트래킹 거부를 나타냄

P3P

웹 사이트 상의 프라이버시 정책에 P3P(The Platform for Privacy Preferences)를 사용하는 것으로 , 프로그램이 읽을 수 있는 형태로 나타내기 위한 HTTP 리스폰스 헤더

---