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

3장 HTTP 메시지

이번 장에서 다룰 내용

• 메시지가 어떻게 흘러가는가
• HTTP 메시지의 세 부분(시작줄, 헤더, 개체 본문)
• 요청과 응답 메시지의 차이
• 요청 메시지가 지원하는 여러 기능(메서드)들
• 응답 메시지가 반환하는 여러 상태 코드들
• 여러 HTTP 헤더들은 무슨 일을 하는가

3.1 메시지의 흐름

HTTP 메시지는 HTTP 애플리케이션 간에 주고 받은 데이터의 블록들이다. 이런 메시지는 방향성이 있어서 몇가지 용어가 등장 한다. '인바운드', '아웃바운드', '업스트림', '다운스트림'

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

간단하게 서버를 기준으로 들어가는 방향이 인바운드, 서버에서 외부로 나가는 방향을 아웃바운드라 한다.

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

클라언트에서 요청을 보내든, 서버에서 응답을 보내든 목적지의 방향을 다운스트림이라고 한다. 그렇기 때문에 Proxy1 입장에서 Proxy2는 요청을 보낼 때는 다운스트림 방향이지만, 응답을 보낼 때는 Proxy1 입장에서 Proxy2는 업스트림이다.

3.2 메시지의 각 부분

메시지는 시작줄, 헤더, 본문으로 구성된다. HTTP 메시지에서는 어디서부터 어디가 헤더고 본문인지 명시하지 않지만 줄바꿈으로 구간을 구분한다. 줄 바꿈을 의미하는 특별한 문자열이 있는데 바로 CRLF(Carriage Return Line Feed) 이다. 이 줄바꿈을 의미하는 문자열은 ASCII 13(Carriage Return)과 ASCII 10(Line Feed) 두 문자로 구성되어 있다. 명세에는 CRLF을 줄 바꿈 문자열로 사용하지만, 유연하고 연고한 애플리케이션은 일반적인 개행문자도 줄 바꿈 문자열로 받아들일 수 있어야 한다고 말한다.

위 메시지를 해석해보자. 이 메시지는 일반 응답 메시지다.

시작줄 : HTTP/1.0 버전 프로토콜로 응답이 됐고 상태 값은 200(성공) 메시지는 OK

헤더: 본문의 내용은 일반 텍스트고 길이가 19

본문: "Hi! I'm a message!" 라는 메시지

3.2.1 메시지 문법

요청 메시지의 형식

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

<헤더>

<엔티티 본문>

응답 메시지의 형식

<버전> <상태 코드> <사유 구절>

<헤더>

<엔터티 본문>

메서드 : GET, POST, PUT, HEAD 등

요청 URL: 완전한 URL또는 경로

버전: HTTP 버전으로 HTTP./<메이저>.<마이너> 로 구성되어 있다.

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

사유 구절: 숫자로 된 상태를 사람이 이해할 수 있게 설명하는 짧은 메시지

헤더: optional 한 정보, 메타 정보 등

본문: 임의의 바이너리 블록으로 많은 양의 데이터를 넣을 수 있는 공간. 본문은 아얘 없을 수도 있는데, 이때에도 헤더가 끝났음을 알리는 CRLF문자를 뺴먹지 말아야 한다.

3.2.2 시작줄

요청 메시지의 시작줄: 요청 메시지에서 무엇을 원하는지 나타낸다. 메서드는 GET, 리소트는 /test/hi-there.txt 이고 프로토콜 버전은 HTTP/1.1 이다. 간단히 요청줄이라고도 한다.

응답 메시지의 시작줄: 응답 메시지에서 보내는 수행결과와 상태 정보와 결과 메시지. 응답한 프로토콜 버전은 HTTP/1.0이고 상태 값은 200 응답 사유는 OK 다. 간단히 응답줄이라고도 한다.

메서드: 메서드는 책과 MDN의 설명이 조금 다르다. 아래는 MDN 내용을 가져온 것이다. 특히 OPTIONS에 대한 설명이 조금 다르다. 내가 알기에도 OPTIONS는 MDN의 설명이 맞는거 같다.

GET 메소드는 특정 리소스의 표시를 요청합니다. GET을 사용하는 요청은 오직 데이터를 받기만 합니다.

HEAD 메소드는 GET 메소드의 요청과 동일한 응답을 요구하지만, 응답 본문을 포함하지 않습니다.

POST 메소드는 특정 리소스에 엔티티를 제출할 때 쓰입니다. 이는 종종 서버의 상태의 변화나 부작용을 일으킵니다.

PUT 메소드는 목적 리소스 모든 현재 표시를 요청 payload로 바꿉니다.

DELETE 메소드는 특정 리소스를 삭제합니다.

CONNECT 메소드는 목적 리소스로 식별되는 서버로의 터널을 맺습니다.

OPTIONS 메소드는 목적 리소스의 통신을 설정하는 데 쓰입니다.

TRACE 메소드는 목적 리소스의 경로를 따라 메시지 loop-back 테스트를 합니다.

PATCH 메소드는 리소스의 부분만을 수정하는 데 쓰입니다.

책에서 설명하는 OPTIONS은 서버가 어떤 메서드를 수행할 수 있는지 확인 한다. 근데 이렇게 동작하기도 하지만, 어쨋든 본격적인 요청을 하기 전에 OPTIONS 메소드를 보내는 것도 있는 것으로 알고 있다.

엔드 포인트마다 메서드가 다를 텐데??? 메서드를 종류를 받는것도 좀 모르겠다.

상태 코드

공식적으로 정의된 범위가 있긴 한데, 대략적으로 구분하는 것은 좋아도 서버에서 세세하게 구분하는 것이 옳을까 하는 의문은 있다.

필요할 때 MDN을 참고 하지만,

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status

상태코드는 100단위로 종류를 구문한다.

100번대 : 정보를 나타냄,

200번대: 응답 성공

300번대: 리다이렉션

400: 클라이언트 에러

500: 서버 에러

클라이언트에서 잘못한 것이면 400대를, 서버 내부에서 문제가 발생한 것이면 500에러를 주자.

사유 구절의 예

200 OK

401 Unauthorized

404 NotFound

버전 정보

클라이언트가 HTTP/1.0을 요청했을 때 버전이 다른 HTTP/1.1 을 사용하는 서버가 응답할 수 있다.

근데 이 때 주의해야 할 것은 응답 메시지 프로토콜이 HTTP/1.1 이 아닐 수 있다. 몇몇 서버의 경우는 실제 메시지가 아니라 여러 프로토콜을 사용할 수 있고 이 경우에는 HTTP/1.0으로 응답을 했을 수도 있다. 그럼 왜 HTTP/1.1을 나타냈냐 인데. 서버에서 자신이 보낼 수 있는 가장 높은 버전을 응답 메시지에서 사용한 프로토콜에 상관없이 보내는 경우가 있다고 한다. 그리고 HTTP/1.3 보다 HTTP/1.22가 더 높은 버전이다. 마이너 버전이 3 vs 22가 되는것이기 때문이다.

3.2.4 엔터티 본문

다양한 형태의 본문을 포함할 수 있다.

3.25 버전 0.9 메시지

이 버전에서는 시작줄, 헤더, 본문이 없다. 완전 단순

3.3 메서드

서버 마다 응답할 수 있는 메서드 범위가 다를 수 있다.

3.3.1 안전한 메서드

GET, HEAD를 안전한 메서드라고 하는데, 서버에 어떤 데이터도 저장하지 않고 결과도 반영하지않기 때문이다.

3.3.2 GET 리소스를 요청한다.

3.3.3 HEAD

본문을 포함하지 않는 GET이라 할 수 있다. 본문을 포함하지 않는데 무슨 소용이냐 할 수 있는데, 리소스를 다 가져오지 않고 헤더나 시작줄의 정보만 알아볼때 사용한다고 한다.

3.3.4 PUT 전통적으로는 리소스 위치에 사용자가 입력한 엔터티 바디 내용을 넣은 페이지를 생성하는 것

3.3.5 POST 사용자가 입력한 데이터를 전송

3.3.6 TRACE

동작은 이미지를 보면서 설명하겠다.

클라이언트에서 TRACE 메시지를 보내면 중간에 프록시 같은 애들이 헤더 쪽에 값을 넣어주고 서버쪽에서 루프백 진단을 한 다음에 본문에 내용을 넣어서 클라이언트에게 전달한다. 이때 클라이언트에서 엔터티 바디를 사용하지 않은 점을 기억하자.

3.3.7 OPTIONS

사용 가능한 메서드를 알려준다고 한다.

실제로 google에 날렸을 때 받은 응답이다.

MDN의 경우는 그냥 GET처럼 동작했다.

3.3.8 DELETE 데이터를 지운다.

3.3.9 확장 메서드 이건 별로 관심 없다.

3.4 상태 코드

상태 코드는 클라이언트에게 쉽게 결과를 나타낸다고 한다.

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

여기서 100 Continue 에 대해 설명을 쭉 해주는데, 데이터를 주고 받는 효율성을 높일 수 있을까? 잘 모르겠다.

3.4.2: 성공 상태 코드

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status 참고 ^^

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

리다이렉션은 과거에 페이지 단위 웹을 할 때는 내가 로컬에 갖고 있는 데이터가 최신인 것이 맞는지 확인하여, 최신이 아니면 리다이렉트 해서 다시 리소스를 가져오도록 구성하기 위한 것 같다. 그러나 이 방법은 이제 별로 유용하지 않을 것 같다.

3.4.4 400-499: 클라이언트 에러

파라미터를 잘못 넣었든 , 리소스 경로를 잘못했든 문제

3.4.5 500-599: 서버 에러 상태

요청이 서버로는 갔지만, 서버 로직을 수행하다 에러

3.5 헤더

일반 헤더: Date와 같이 서버 클라이언트 공동으로 사용하는것

요청 헤더: 요청 메시지에서 사용하는 헤더 값 (예: Accept: *)
응답 헤더: 응답 메시지에서 사용하는 헤더 값 (예: Server: Tiki-Hut/1.0)

엔터티 헤더: 엔터티 본문의 메타 데이터 (예: Content-Type: text/html)

확장 헤더: 비표준 헤더들

검색하다가 엄청 깔끔하게 정리하신분이 계셔서 링크를 남긴다.

heejeong Kwon님의 블로그 - HTTP 헤더의 종류 및 항목

3.5.1 일반 헤더

3.5.2 요청 헤더

3.5.3 응답 헤더

3.5.4 엔터티 헤더

조건 부 헤더가 있어서 다양한 처리를 할 수 있지만, 가능하면 헤더에서가 아니라 로직에서 처리하는게 좋을 것 같다.