1부 3장 - HTTP 메시지

3.1 메시지의 흐름

HTTP 메시지는 HTTP 애플리케이션 간에 주고받은 데이터의 블록들.

3.1.1 메시지는 원 서버 방향을 인바운드로 하여 송신된다.

인바운드로 이동: 메시지가 원 서버로 향하는 것.

아웃바운드로 이동: 모든 처리가 끝난 뒤에 메시지가 사용자 에이전트로 돌아오는 것.

3.1.2 다운스트림으로 흐르는 메시지

요청이나 응답 메시지에 관계 없이 모든 메시지는 다운스트림으로 흐른다.

3.2 메시지의 각 부분

메시지는 클라이언트로부터의 요청이나 서버로부터의 응답 중 하나를 포함.

시작줄, 헤더 블록, 본문 세 부분으로 이루어짐

시작줄 - 어떤 메시지인지 서술	줄 단위로 분리된 아스키 문자열
헤더 블록 - 속성
본문(option) - 데이터	선택적인 데이터 덩어리. 텍스트 or 이진 데이터 or 비어있음

3.2.1 메시지 문법

모든 HTTP 메시지는 요청 메시지나 응답 메시지로 구분된다.

- 요청 메시지의 형식 ( 웹 서버에 어떤 동작을 요구 )

메서드; 요청 URL; 버전

헤더

엔터티 본문

- 응답 메시지의 형식 ( 요청의 결과를 클라이언트에 돌려줌 )

버전; 상태코드; 사유 구절;

헤더

엔터티 본문

메서드:     클라이언트 측에서 서버가 리소스에 대해 수행해주길 바라는 동작

요청         URL: 요청 대상이 되는 리소스를 지칭하는 완전한 URL 혹은 URL의 경로 구성 요소

버전:        사용중인 HTTP의 버전

상태코드: 요청 중에 무엇이 일어났는지 설명하는 세 자리의 숫자

사유구절: 상태 코드의 의미를 사람이 이해할 수 있게 설명해주는 짧은 문구

헤더들:    이름, 콜론, 선택적인 공백, 값, CRLF가 순서대로 나타나는 0개 이상의 헤더들.

엔터티 본문: 임의의 데이터 블록을 포함한다. 

3.2.2 시작줄

모든 HTTP 메시지는 시작줄로 시작함

- 요청줄: 서버에서 어떤 동작이 일어나야 하는지 설명해주는 메서드, 그 동작에 대한 대상을 지칭하는 요청 URL, HTTP 버전을 포함함.

- 응답줄: 응답 메시지에서 쓰인 HTTP의 버전, 숫자로 된 상태코드, 수행 상태에 대해 설명해주는 사유 구절이 포함.

- 메서드: 서버에게 무엇을 해야 하는지 말해줌. 메서드에 따라 요청 메시지에 본문이 있는 경우도 있고 그렇지 않은 경우도 있음.

- 상태코드: 클라이언트에게 무엇이 일어났는지 말해줌. 

   응답 메시지의 시작줄에 담겨 반환됨.

   세 자리 숫자로 된 코드값을 기준으로 묶임

전체 범위	정의된 범위	분류
100 - 199	100 - 101	정보
200 - 299	200 - 206	성공
300 - 399	300 - 305	리다이렉션
400 - 499	400 - 415	클라이언트 에러
500 - 599	500 - 505	서버 에러

- 사유구절: 상태 코드에 대한 글로 된 설명을 제공

- 버전번호: 요청과 응답 메시지 양쪽 모두에 기술됨.

   HTTP로 대화하는 애플리케이션들에게 대화 상대의 능력과 메시지의 형식에 대한 단서를 제공해주기 위한 것.

   버전 번호는 분수가 아니다.

   ex) HTTP/2.22는 HTTP/2.3보다 크다.

3.2.3 헤더

요청과 응답 메시지에 추가 정보를 더함.

기본적으로 이름 / 값 쌍의 목록

- 헤더 분류

애플리케이션은 자유롭게 자신만의 헤더를 만들어 낼 수 있다.

일반 헤더: 요청과 응답 양쪽에 모두 나타날 수 있음.

요청 헤더: 요청에 대한 부가 정보를 제공.

응답 헤더: 응답에 대한 부가 정보를 제공.

Entity 헤더: 본문 크기와 콘텐츠, 혹은 리소스 자체를 서술.

확장 헤더: 정의되지 않은 새로운 헤더.

ex) Date: Tue, 3 Oct 1997 02:16:03 GMT

      Content-length: 15030

3.2.4 엔터티 본문

메시지의 화물. 여러 종류의 디지털 데이터를 실어 나를 수 있음

3.3 메서드

모든 서버가 모든 메서드를 구현하지는 않는다는 것에 주의.

3.3.1 안전한 메서드 (Safe Method)

GET, HEAD는 안전하다고 할 수 있음. 요청 결과가 서버에 어떤 작용도 없기 때문. 요청의 결과로 인해 서버에서 일어나는 일은 아무것도 없다는 의미.

안전한 메서드의 목적은, 서버에 영향을 줄 수 있는 안전하지 않은 메서드가 사용될 때 사용자들에게 그 사실을 알려주는 HTTP 애플리케이션을 만들 수 있도록 하는 것에 있다.

3.3.2 GET

가장 흔함. 주로 서버에게 리소스를 달라고 요청하기 위해 쓰임.

3.3.3 HEAD

GET 처럼 행동하지만, 서버는 응답으로 헤더만 돌려준다. (본문 X)

장점

- 리소스를 가져오지 않고도 무엇인지 알아냄.

- 응답의 상태 코드를 통해, 개체가 존재하는지 확인

- 리소스가 변경 되었는지 검사 가능

서버 개발자들은 반환되는 헤더가 GET으로 얻는 것과 정확히 일치함을 보장해야 함.

3.3.4 PUT

서버에 문서를 쓴다.

서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 이미 URL이 존재한다면 본문을 사용해서 교체하는 것

3.3.5 POST

서버에 입력 데이터를 전송하기 위해 설계됨.

POST: 서버에 데이터를 보내기 위해 사용.

PUT: 서버에 있는 리소스에 데이터를 입력하기 위해 사용.

3.3.6 TRACE

클라이언트가 어떤 요청을 할 때, 그 요청은 방화벽, 프락시, 게이트웨이 등의 애플리케이션을 통과할 수 있다.

이들은 원래의 HTTP 요청을 수정할 수 있는 기회가 있다.

이 메서드는 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려준다.

요청 전송의 마지막 단계에 있는 서버는 자신이 받은 요청 메시지를 본문에 넣어 TRACE 응답을 되돌려준다.

클라이언트는 자신과 목적지 서버 사이의 모든 HTTP 애플리케이션의 요청 / 응답 연쇄를 따라가면서 자신이 보낸 메시지의 상태를 확인할 수 있다.

TRACE는 주로 진단을 위해 사용.

ex) 요청이 의도한 요청 / 응답 연쇄를 거쳐가는지, 프락시나 다른 애플리케이션이 요청에 어떤 영향을 미치는지

3.3.7 OPTIONS

서버에게 특정 리소스에 대해 어떤 메서드가 지원되는지 물어볼 수 있음

여러 리소스에 대해 실제로 접근하지 않고도 그것들을 어떻게 접근하는 것이 최선인지 확인할 수 있는 수단을 제공.

3.3.8 DELETE

서버에게 요청 URL로 지정한 리소스를 삭제할 것을 요청한다.

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

3.3.9 확장 메서드

HTTP/1.1 명세에 정의되지 않은 메서드.

" 엄격하게 보내고 관대하게 받아들여라 "

3.4 상태 코드

상태 코드는 클라이언트에게 그들의 트랜잭션을 이해할 수 있는 쉬운 방법을 제공함.

3.4.1 100-199: 정보성 상태 코드 (책 참조: 68~69p)

3.4.2 200-299: 성공 상태 코드 (표 참조: 70p)

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

리소스에 대해 다른 위치를 사용하라고 말해주거나 그 리소스의 내용 대신 다른 대안 응답을 제공한다. 몇몇은 리소스에 대한 애플리케이션의 로컬 복사본이 원래 서버와 비교했을 때 유효한지 확인하기 위해 사용됨.

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

클아이언트가 서버에게 잘못된 요청을 보낸 후 응답 코드

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

서버 자체에서 에러가 발생하는 경우

3.5 헤더

일반 헤더: 클라이언트와 서버 양쪽 모두가 사용.

요청 헤더: 요청 메시지를 위한 헤더.

 서버에게 클라이언트가 받고자 하는 데이터의 타입이 무엇인지와 같은 부가 정보를 제공.

응답 헤더: 클라이언트에게 정보를 제공하기 위한 헤더.

엔터티 헤더: 엔터티 본문에 대한 헤더.

확장 헤더: 애플리케이션 개발자들에 의해 만들어진 비표준 헤더.

3.5.1 일반 헤더

메시지에 대한 아주 기본적인 정보 제공.

- 일반 캐시 헤더: 매번 원 서버로부터 객체를 가져오는 대신 로컬 복사본으로 캐시할 수 있도록 해주는 헤더.

3.5.2 요청 헤더

요청 메시지에서만 의미를 갖는 헤더.

요청이 최초 발생한 곳에서 누가 혹은 무엇이 그 요청을 보냈는지에 대한 정보나 클라이언트의 선호나 능력에 대한 정보를 준다.

- Accept 관련 헤더: 클라이언트가 무엇을 원하고 무엇을 할 수 있는지, 원치 않는 것은 무엇인지 알려줌.

클라이언트는 그들이 원하는 것을 얻고, 서버는 클라이언트가 사용할 수 없는 것을 전송하는 데 시간, 대역폭을 낭비하지 않는다.

- 조건부 요청 헤더: 클라이언트는 서버에게 요청에 응답하기 전에 먼저 조건이 참인지 확인하게 하는 제약을 포함시킬 수 있다.

3.5.3 응답 헤더

- 협상 헤더: ex) 각각 다른 언어의 HTML 문서가 있는 경우, 어떤 문서를 택할 것인가를 지원함.

3.5.4 엔터티 헤더

양 타입의 메시지에 모두 나타날 수 있음.

엔터티에 대한 광범위한 정보를 제공.

- 콘텐츠 헤더: 엔터티의 콘텐츠에 대한 구체적인 정보 제공

- 엔터티 캐싱 헤더: ex) 리소스에 대해 캐시된 사본이 유효한 지 정보. 캐시된 리소스가 더이상 유효하지 않게 되는 시점 추정의 단서.