[http 완벽 가이드] 3장 HTTP 메시지

이 내용은 http 완변 가이드란 책을 읽고 정리한 내용입니다.

 

더 자세한 내용이 궁금하시면 책을 직접 읽어보시는 걸 추천합니다.

 

3장 HTTP 메시지

• HTTP - 인터넷 배달원
• HTTP 메세지 - 소포

로 비유할 수 있다.

1 메세지의 흐름

• 클라이언트, 서버 , 프락시 사이를 흐른다.
• HTTP 메시지
  • 주고받은 데이터들의 블록
  • 내용과 의미를 설명하는 텍스트 메타 정보로 시작
    • 그다음에는 선택적으로 데이터가 온다.
• 용어
  • 인바운드 && 아웃바운드
  • 업스트림 && 다운스트림

인바운드 && 아웃바운드

• 트랜잭션 방향을 표현하기 위해 사용
• 서버방향으로 통신하는 것 : 인바운드
• 클라이언트 방향으로 통신하는 것: 아웃바운드

업스트림 && 다운 스트림

• 모든 데이터는 다운스트림으로 흐른다.

 

• 클라이언트 → 서버:프락시에게 클라이언트는 업스트림이다.
• 클라이언트 → 서버:클라이언트에게 서버는 다운스트림이다.

2. 메시지의 각 부분

• 메시지
  1. 시작줄: 어떤 메시지인지 서술
  2. 헤더 : 속성
  3. 본문: 데이터를 담고있다.
     • 본문은 아예없을 수 있음
• 시작줄과 헤더는 그냥 줄 단위로 분리된 아스키 문자열
  • 각줄은 ‘CRLF’라는 줄바꿈 문자열을 쓴다.
  • 견고한 애플리캐이션이라면 개행 물자도 받을 수 있어야한다.
• 본문은 텍스트나 이진 데이터도 포함할 수도 있다.

2.1 메시지 문법

• 요청 메시지

<메서드><요청URL><버전>
<헤더>

<엔터티 본문>

• 응답메시지
• <버전><상태코드><사유구절> <헤더> <엔터티 본문>
• 메서드GET , HEAD, POST 와 같은 한 단어로 되어 있다.
• 클라이언트 측에서 서버가 리소스에 대해 수행해주길 바라는 동작이다.
• 요청 URL
  • 요청 대상이 되는 리소스를 지칭하는 완전한 URL 혹은 URL의 경로 구성요소
  • 경로 구성요소라 해도, 클라이언트가 서버와 직접 대화하고 있고,
  • 경로 구성요소가 리소스를 가리키는 절대 경로이기만 하면 대체로 문제가 없다.
• 버전
  • HTTP 버전 형식
  • HTTP/<메이저>.<마이너>
  • 중요한점은 메이저 마이너는 모두 정수이다.
• 상태 코드
  • 각 코드의 첫 번째 자릿 수는 상태의 일반적인 분류(성공 or 에러 등을) 나타낸다
• 사유 구절
  • 상태코드를 설명해주는 구절
  • 상태코드 이후부터 줄바꿈까지가 사유구절이다.
  • 오로지 사람에게 읽히기 위한것으로
  • 200 NOT OK == 200 OK
  • 달라보이지만 상태코드가 같으므로 같은 의미이다.
• 헤더들
  • 이름 , 콜론(:) , 선택적인 공백 , 값, CRLF가 순서대로 나타나는 0개 이상의 헤더들
  • 이 헤더들의 끝을 빈줄(CRLF)로 끝내서 엔터티 본문과 헤더 목록을 구별한다.

 

• 엔터티 본문
  • 임의의 데이터 블록을 포함한다.
  • 모든 메시지가 엔터티 본문을 갖는건 아니므로 때떄로 그냥 CRLF로 끝나는 경우도 있다
  • 헤더나 엔터티 본문이 없더라도 항상 CRLF로 끝내야함을 주의 해야함
    • 규칙을 잘 안지키는 구현체와의 호환을 위해 CRLF로 끝나지 않더라도 받아들일 수 있게 해야한다.

2.2 시작줄

• 요청줄
  • 공백으로 구분하는걸 주의
  • HTTP/1.0버전 이전에는 요청줄에 HTTP버전이 필요없음
• 요청메서드(공백)요청URL(리소스)(공백)HTTP버전
• 응답줄
• HTTP버전(공백)상태코드(공백)사유구절
• 메서드

  메서드	설명	메시지 본문이 있는가?
  GET	서버에게 어떤 문서를 가져온다.	없음
  HEAD	서버에서 어떤 문서에 대해 헤더만 가져온다.	없음
  POST	서버가 처리해야 할 데이터를 보낸다.	잇음
  PUT	서버에 요청 메시지의 본문을 저장한다.	있음
  TRACE	메시지가 프락시를 거쳐 서버에 도달하는 과정을 추적한다.	없음
  OPTIONS	서버가 어떤 메서드를 수행할 수 있는지 확인한다.	없음
  DELETE	서버에서 문서를 제거한다.	없음
  - 모든 서버가 위 메서드를 모두 구현한 것은 아니다.
  - 그리고 HTTP는 쉽게 확장할 수 있도록 메서드를 추가할 수 있다.

    →이를 확장 메서드라 부른다.

• 요청 시작줄에 서버에게 무엇을 해야 하는지 말해줌
• 상태코드
  • 요청에 대한 응답을 숫자로 표기해놓은것
  • 100 ~ 199 →정보
  • 200 ~ 299- > 성공
  • 300 ~ 399 → 리다이렉션
  • 400 ~ 499 → 클라이언트 에러
  • 500 ~ 599 → 서버에러
  • 이 범위내에 상태코드가 전부 정의 된것이 아니다.
  • 인식할 수 없는 상태코드를 만난다면 프로토콜의 확장으로 그것을 정의했을 가능성이 높다.
  • 그래서 인식할 수 없는 코드를 만난다면 예(515) 이것을 서버에러로 판별하고 처리해야 한다.
• 사유구절
  • 상태코드는 컴퓨터가 이해 할 수 있는 코드라면
  • 사유 구절은 사람이 이해할 수 있게하는 문법이다.
  • HTTP는 사유구절이 어때야 한다는 업격한 규칙도 제공하지 않는다.
  • → 즉, 사람이 이해할 수 있게만 하면 됨
• 버전 번호
  • HTTP/x.y 형식
  • 자신이 따르는 HTTP 버전을 상대방에게 알려주기 위함
  • 1.1 버전 애플리케이션과 대화하는 1.2 버전 애플리캐이션은 1.1문법만 사용할 수 있다.
  • 응답 메시지에서 오는 버전(ex 1.1)은 그 메시지가 1.1 버전이라는 의미가 아니다.
  • 1.1 버전까지 받을 수 있다는 의미이다.
  • 그리고 버전이 분수가 아님을 주의해야한다.
  • 1.24 는 1.3 보다 높은 버전이다. 24 가 3보다 높기 때문

2.3 헤더

• 시작줄 다음에 오는 이름/값 쌍의 목록
  • HTTP 헤더 명세는 여러 헤드 필드를 정의한다.
  • 또한 자유롭게 자신만의 헤더를 정의할 수 있음
  • - 일반헤더
  • 요청과 응답 양쪽에 모두 나타날 수 있음
  • -요청 헤더
  • 요청에 대한 부가 정보를 제공
  • -응답헤더
  • 응답에 대한 부가 정보를 제공
  • -Entity 헤더
  • 본문 크기와 콘텐츠, 혹은 리소스 그 자체를 서술
  • -확장 헤더
  • 명세에 정의되지 않은 새로운 헤더
  •  
  • 이름: 공백(없어도 됨) 필드값으로 구성되어있으며
  • CRLF를 통해 헤더를 여러줄로 나눈다.
• 헤더 분류

2.4 엔터티 본문

• 엔터티는 트랜잭션을 하는 이유인 리소스에 관한 내용을 담고있다.
• 이미지,비디오 HTML문서 , 소프트웨어 …등과 같은 디지털 데이터를 담는다.

2.5 버전 0.9 메시지

• 0.9버전은 버전 번호도 없고
• 응답 메시지는 오로지 엔터티 본문만 보냈다.

3. 메서드

• 1.1버전과 호환하고 싶다면 GET과 HEAD만 구하는 것으로 충분하다.

3.1 안전한 메서드(Safe Method)

• GET 과 HEAD는 안전한 메서드이다.
  • 이는 HTTP요청의 결과로 서버에 어떤 작용도 없으므로
• POST같은 메서드를 요청할 시 서버는 어떠한 일이 일어나므로 안전한 메서드가 아니다.
• 브라우저가 안전하지 않은 요청(비번변경, 결제 , 수정 …)을 요구할 시 경고 메시지 같은 걸로 이를 브아우저에게 알려야한다.

3.2 GET

• GET은 가장 많이 쓰이는 메서드이다.
• 주로 리소스를 달라고 요청하기 위해 쓰인다.
• 1.1은 반드시 구현해야 한다.

3.3 HEAD

• GET처럼 행동한다. 다른점은 엔터티 본문을 반환하지 않는다는 점
• 리소스를 가져오지 않고도 리소스에 대해 무엇인가를 알아낼 수 있다.
• 응답의 상태코드를 통해, 개체가 존재하는지 확인할 수 있다.
• 헤더를 확인하여 리소스가 변경되었는지 검사할 수 있다.
• 서버 개발자는 HEAD가 반환하는 헤더가 GET으로 반환하는 리소스의 헤더와 일치하게 코딩해야한다.

3.4 PUT

• PUT은 서버에 문서를 쓴다.
• 서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 이미 URL이 존재한다면 본문을 사용해서 교체한다.
• PUT은 콘텐츠를 변경할 수 있게 하기 때문에 많은 서버가 수행하기 전 로그인을 요구한다.

3.5 POST

• POST 메서드는 서버에 입력 데이터를 전송하기 위해 설계되었다.
• 실제로 HTML 폼을 지원하기 위해 흔히 사용된다.
• 채워진 폼에 담긴 데이터는 서버로 전송되며, 서버는 이를 모아서 필요로 하는 곳(예를 들면 그 데이터를 처리할 서버 게이트웨이 프로그램)에 보낸다.

3.6 TRACE

• 클라이언트가 어떤 요청을 할때, 그 요청은 방화벽, 프락시, 게이트웨이 등의 애플리케이션을 통과할 수 있다.
• 이 애플리케이션들은 요청을 수정할 수 있는 기회가 있다.
• TRACE메서드는 자신이 보낸 요청이 서버에게 어떻게 보여지는지 알려준다.
• 요청 전송에 마지막 단계에 있는 서버는 자신이 받은 요청 메시지를 본문에 넣어 TRACE 응답에 돌려준다.
• 주로 위와 같은 진단을 위해 사용된다.
• 하지만 TRACE요청에 대한 응답 결과를 보고 다른 메서드들이 동일하게 처리되는 것이 아니다.GET요청은 웹 캐시와 같은 다른 HTTP 애플리 캐이션으로 전송한다.중간 애플리케이션이 결정을 내리는 것이 일반적이다.
• TRACE는 어떻게 구별하는지에 대한 메커니즘이 없다.
• 예를 들어 POST요청을 프락시는 바로 서버에 통과시키는 반면
• TRACE 요청은 어떤 엔터티 본문도 포함할 수 없고 응답에는 서버가 받은 요청 메시지를 본문에 넣어 보낸다.

3.7 OPTIONS

• OPTIONS 메서드는 웹서버에게 여러 가지 종류의 지원 범위에 대해 물어본다.
• 서버에게 특정 리소스에 대해 어떤 메서드가 지원되는지 물어볼 수 있다.
• 이는 서버는 특정 종류의 객체에 대해 특정 동작만을 지원하기 때문
• 이 메서드는 여러 리소스에 대해 실제로 접근하지 않고도 그것들을 어떻게 접근하는 것이 최선인지 확인할 수 있다.

3.8 DELETE

• 서버에게 리소스를 삭제할 것을 요청한다.
• 하지만 서버는 그 리소스를 삭제하는 것을 보장하지 않는다.
  • 이는 HTTP 명세는 서버가 클라이언트에게 알리지 않고 요청을 무시하는것을 허용하기 때문

3.9 확장 메서드

• HTTP는 명세에 정의되지 않은 메서드를 확장해도 문제가 되지 않는다.
• 어떤 확장 메서드는 형식을 갖춘 명세로 정의되었지만, 아니란 점도 주의해야함
• 만약 어떤 확장 메서드를 정의한다면 대부분의 애플리케이션은 이해할 수 없을 것이다.
• 마찬가지로 이해할 수 없는 확장 메서드를 사용하는 애플리케이션과 마주칠 수 있다.
• 이런 상황에서는 관용적인것이 좋다.
  • 프락시는 종단 간(end to end ) 행위를 망가뜨리지 않는다면 서버로 이를 전달하려 한다.
• 그렇지 않다면 프락시는 501 NOT Implemented 상태 코드로 응답해야한다.

4. 상태코드

4.1 100-199: 정보성 상태코드

• 1.1 버전부터 도입되었다.

구간	상태코드	사유구절	설명
100 ~ 1xx	100	Continue	클라이언트의 요청의 일부가 받아들여졌으며, 클라이언트는 계속해서 요청의 나머지를 계속 이어서 보내야함을 의미하는 상태
	101	Switching Protocols	서버가 프로토콜을 바꾸었음을 나타내는 상태
- 100 continue
- 클라이언트가 서버에 엔터티 본문을 전송하기 전에 그 엔터티 본문을 서버가 받아들일 것인지 확인하려고 할 때, 그 확인 작업을 최소화하기 위한 의도로 도입된 것
- 이는 혼동이 잘오는 개념으로 더 자세히 보면

클라이언트와 100 continue

• 클라이언트가 엔터티를 보내려 하고 그 전에 100continue 응답을 기다리겠다면
• 클라이언트는 100-continue로 하는 Except 요청 헤더를 보내야 한다.
• 만약 보내지 않는다면 100-continue Except 요청 헤더를 보내지 말아야한다.
• 100-continue는 최적화를 위한 것으로 서버가 받아들일 수 없는 큰 엔터티를 서버에게 보내지 않으려는 목적으로만 사용해야한다.
• Except 요청 헤더를 보내고 100-continue라는 응답이 올때까지 클라이언트는 기다리면 안된다. 요청 헤더를 보내고 약간의 타임아웃 후 바로 보내야한다.

서버와 100 continue

• 서버는 Except 요청 헤더를 받는다면 100-continue 응답 혹은 에러를 보내야한다.
• 서버는 절대로 100-continue 응답을 받을 것을 의도하지 않은 클라이언트에게 100 continue 상태코드를 보내서는 안된다. → 하지만 몇몇 잘못된 서버들은 그런다.
• 만약 100 continue 응답을 보내기 전 엔터티를 수신하였다면, 서버는 100 응답을 보낼 필요가 없다.
• 만약 100요청을 받고 엔터티 본문을 읽기 전 요청을 끝낸다면(에러등의 이유로) 연결을 닫아서는 안된다. 이는 4장의 TCP 끊기와 리셋 에러에서 다룬다.

프락시와 100 continue

• 클라이언트로 부터 100-continue 응답을 의도한 요청을 받는다.
  1. 다음 홉(6장에서 다룬다) 서버가 1.1버전 혹은 버전을 모른다면
     1. Excpect 헤더를 포함시켜서 요청을 다음으로 전달한다.
  2. 만약 다음 홉 서버가 1.1 이전의 버전을 따른다면
     1. 417애러로 응답한다.
• 만약 프락시가 1.1 이전 버전을 따르는 클라이언트를 대신하여 Expect헤더와 100-continue값을 요청에 포함시키기로 했다면 응답에는 100-continue응답을 해선 안된다.
  • 이유는 클라이언트는 100을 모르기 때문

4.2 200-299: 성공 상태 코드

구간	상태코드	사유구절	설명
200 ~ 299	200	OK	요청을 정상적으로 처리하였고 본문에 요청된 리소스를 포함하고 있는 상태
	201	Created	서버에 개체를 생성하라는 요청을 위한 성공 상태
	202	Accepted	서버는 클라이언트의 요청에 대하여 수용하였으나, 아직 그 어떤 동작도 수행하지 않은 상태
	203	Non-Autohritative Information	헤더에 들어있는 정보가 리소스 사본에서 왔으며, 리소스에 대한 메타 정보를 검증하지 못한 경우 응답하는 상태
	204	No Content	요청을 정상적으로 처리하였고 본문을 포함하지 않는 상태
	205	Reset Content	브라우저에게 현재 페이지에 있는 HTML 폼에 채워진 모든 값을 비우라는 것을 알려주기 위한 상태
	206	Paritail Content	클라이언트의 요청에 대하여 부분 혹은 범위적인 성공을 나타내는 상태

4.3 300-399:리다이렉션 상태코드

• 리다리엑션 코드는 클라이언트의 요청 리소스에 대해 다른 위치를 사용하라고 말해주거나 리소스의 내용 대신 다른 대안 응답을 제공한다.
• 만약 옮겨 졌다면, 클라이언틍게 리소스가 옮겨졌으며 어디서 찾을 수 있는지 알려주기 위해 3xx 상태코드와 Location 헤더를 보낼 수 있다.

구간	상태코드	사유구절	설명
300 - 3xx	300	Multiple Cohoices	클라이언트가 동시에 여러 리소스를 가리키는 URL을 요청한 경우, 그 리소스의 목록과 함께 반환하는 상태
	301	Moved Permanently	요청한 URL이 옮겨졌을 때 사용되는 상태.Location 헤더에 현재 리소스가 존재하고 있는 URL을 포함해야 함.
	302	Found	요청한 URL이 옮겨졌을 때 사용되는 상태.Location 헤더의 URL은 임시로 이동되는 목적으로 사용되며 이후의 요청에서는 원래의 URL을 사용해야 함.
	303	See Other	클라이언트에게 리소스를 다른 URL에서 가져올 것을 말하고자 할 때 사용되는 상태.Location 헤더에 현재 리소스가 존재하고 있는 URL을 포함해야 함.303 상태코드의 주 목적은 POST 요청에 대한 응답이며 GET 요청으로 리다이렉트 시킨다.
	304	Not Modified	클라이언트는 If-Modified-Since 헤더를 사용하여 조건부 요청을 할 수 있다. 조건부 헤더의 정보를 바탕으로 서버의 리소스가 수정된 사항이 없을 경우 반환하는 상태.304 상태는 리소스 수정이 없기때문에 응답 본문이 존재하지 않는다.
	305	Use Proxy	리소스가 반드시 프록시를 통해서 접근되어야 함을 나타내기 위해 사용되는 상태.
	307	Temporary Redirect	요청한 URL이 옮겨졌을 때 사용되는 상태.Location 헤더의 URL은 임시로 이동되는 목적으로 사용되며 이후의 요청에서는 원래의 URL을 사용해야 함.

4.4 400-499: 클라이언트 에러 상태코드

• 클라이언트가 서버에서 다룰 수 없는 무엇인가를 보낼때 쓰인다.
• 잘못 구성된 메시지일 수 있으며 , 서버가 알 수 없는 리소스를 요청할 때 404 Not Found를 보내곤 한다.

구간	상태코드	사유구절	설명
400 ~ 4xx	400	Bad Request	클라이언트의 요청이 잘못된 것을 알려주는 상태
	401	Unauthorized	인증이 되지 않은 클라이언트에게 인증을 요구하기 위한 상태
	402	Payment Required	현재 사용되지 않는 상태
	403	Forbidden	서버에서 클라이언트의 요청을 거부하고자 할 때 사용되는 상태. 인증은 되었으나 허가되지 게시물에 접근하고자 할 때 발생 할 수 있음.
	404	Not Found	존재하지 않는 URL에 접근할 때 응답하는 상태
	405	Method Not Allowed	요청한 URL에 대하여 지원하지 않는 메서드의 요청을 받았을 때 사용하는 상태.Allow 헤더를 포함하여 클라이언트가 인지할 수 있도록 한다.
	406	Not Acceptable	클라이언트가 요청한 URL에 대한 리소스 중 클라이언트가 받아들일 수 있는 것이 없는 경우 사용되는 상태
	407	Proxy Authentication Required	접근하는 리소스에 대한 인증을 요구하는 프락시 서버를 위해 사용되는 상태
	408	Request Timeout	클라이언트의 요청을 완수하기에 시간이 너무 많이 걸리는 경우, 서버는 408 상태를 응답하면서 연결을 끊을 수 있음.
	409	Conflict	클라이언트의 요청이 리소스의 충돌을 일으킬 염려가 있을 때 사용되는 상태
	410	Gone	404 상태와 비슷하나 한 때, 서버가 해당 리소스를 갖고 있었을 경우 응답하는 상태
	411	Length Required	서버가 클라이언트의 요청에 Content-Length 헤더가 있을 것을 요구할 때 사용하는 상태
	412	Precondition Failed	클라이언트가 조건부 요청을 하였을 경우, 그 중 하나가 실패했을 때 사용하는 상태
	413	Request Entity Too Large	서버가 처리할 수 있는 한계를 넘은 크기의 요청을 클라이언트가 보냈을 경우 사용하는 상태
	414	Request URI Too Long	서버가 처리할 수 있는 한계를 넘은 길이의 요청 URL이 포함된 요청을 클라이언트가 보냈을 경우 사용하는 상태
	415	Unsupported Media Type	서버가 이해하지 못한 내용 유형의 헤더 및 본분을 클라이언트가 요청하였을 경우 응답하는 상태
	416	Requested Range Not Satisfiable	리소스의 특정 범위를 요청하였으나, 그 범위가 잘못되었을 경우 사용되는 상태
	417	Expectation Failed	요청에 포함된 Expect 요청 헤더에 서버가 만족시킬 수 없는 기대가 담겨있는 경우 사용되는 상태

4.5 500-599: 서버 에러 상태코드

• 클라이언트는 올바른 요청을 했지만 서버에서 에러가 나는 경우
• 또는 게이트웨이 리소스 같은 서버 보조 구성요소에서 발생한 에러일 수도 있다.

구간	상태코드	사유구절	설명
500 ~ 5xx	500	Internal Server Error	서버가 요청을 처리할 수 없게 만드는 에러가 발생한 경우 응답하는 상태
	501	Not Implemented	클라이언트가 서버의 능력을 넘은 요청을 했을 때 사용하는 상태(서버가 지원하지 않는 메서드로 요청)
	502	Bad Gateway	프록시나 게이트웨이로부터 잘못된 응답을 받았을 경우 사용되는 상태
	503	Service Unavailable	현재 서버에서 요청을 처리해줄 수 없는 상태
	504	Gateway Timeout	프록시나 게이트웨이로부터 응답을 기다리다 발생한 타임아웃에 대한 상태
	505	HTTP Version Not Supported	서버가 지원할 수 없거나 지원하지 않으려고 하는 버전의 프로토콜로 된 요청을 받았을 때 사용하는 상태

5. 헤더

• 헤더의 분류
  • 일반 헤더
  • 요청 헤더
  • 응답 헤더
  • 엔터티 헤더
  • 확장 헤더

일반 헤더

• 클라이언트와 서버 양쪽에서 사용하는 헤더
• 메시지를 만들어지는 일시 같은 것들이 일반헤더
• +일반캐시헤더
• 서버로 부터 객체를 가져오는 대신 로컬 복사본으로 캐시할 수 있도록 해주는 헤더

요청 헤더

• 요청 메시지에 포함하는 헤더
• 받고자 하는 데이터 타입이 무엇인지 같은 부가 정보

+Accept 관련 헤더

• Accept관현 헤더들은 클라이언트가 서버로 부터 무엇을 원하고 무엇을 원하지 않은지 알 수 있는 그래서 시간과 대역폭을 낭비하지 않을 수 있다.

+조건부 요청 헤더

• 클라이언트가 요청에 몇몇 제약을 넣기 위함
• 자신의 사본과 다를때만 사본을 달라는 등의 조건을 걸 수 있음

+요청 보안 헤더

• 인증요구/응답 체계를 가짐
• 요청하는 클라이언트가 어느 정도의 리소스에 접근하기 전에 자신을 인증하게 함으로써 트랜잭션을 더 안전하게 만든다.
• Cookie같은 것들이 있다.

+프락시 요청 헤더

• 프락시의 기능을 돕기 위한 헤더

응답 헤더

• 클라이언트에게 정보를 제공하기 위한 자신만의 헤더를 갖고 있다.
• 누가 응답을 내는지 응답자의 능력은 어떻게 되는지 같은 내용이 있다.

+협상 헤더

• 서버에 독일어랑 프랑스어로 번역된 HTML문서가 있다면, 무엇을 선택할 것인가에 대한 협상할 수 있도록 지원하는 헤더 17장 협상에서 다룬다.

+응답 보안헤더

• 14장 보안에서 자세히 다룸

엔터티 헤더

• 응답이든 요청이든 엔터티를 포함할 수 있기 때문에 광범위하게 쓰임
• 일반적으로 메시지의 수신자에게 자신이 다루고 있는 것이 무엇인지 말해준다.

+콘텐츠 헤더

• 콘텐츠 헤더는 엔터티의 콘텐츠에 대한 구체적인 정보를 제공한다.
• 리소스의 유형, 길이 등등등

+엔터티 캐싱 헤더

• 7장 캐싱에서 다루겠다.

확장 헤더

• HTTP 명세에는 없는 개발자들이 만든 추가 헤더
• HTTP 프로그램은 그 헤더가 무엇인지 몰라도 용인하고 전달할 필요가 있다.