[HTTP] HTTP 메시지 💬

1. 메시지의 흐름

• 인바운드, 아웃바운드, 업스트림, 다운스트림

인바운드 & 아웃바운드

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

• HTTP는 인바운드와 아웃바운드라는 용어를 트랜잭션 방향으로 표현하기 위해 사용한다.
• 인바운드로 이동한다 == 메시지가 원서버 방향으로 향한다.
• 아웃바운드로 이동한다 == (모든 처리가 끝난 뒤) 메시지가 사용자 에이전트로 돌아오는 것

다운스트림 & 업스트림

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

• 다운스트림과 업스트림이란 용어는 발송자와 수신자에 대한것이다.
• HTTP는 강물과 같이 흐른다. 모든 메시지는 요청 또는 응답 메시지냐에 관계없이 다운스트림으로 흐른다.
• 메시지의 발송자는 수신자의 업스트림이다.

(요청에서는 프락시 1이 프락시 3의 업스트림이지만, 응답에서는 프락시 3이 프락시 1의 업스트림이 될 수도 있다.)

2. 메시지의 각 부분

HTTP 메시지는 단순한, 데이터의 구조화된 블록

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

메시지의 구성

• 메시지는 시작줄, 헤더블록, 본문 3가지 파트로 구성된다.
• 시작줄: 이것이 어떤 메시지인지 서술
• 헤더블록: 메시지의 속성을 담고 있음

Content-type: text/plain # 본문이 무엇인지 말해줌
Content-length: 19 # 본문의 크기: 19byte

• 본문: 선택적인 데이터 덩어리 (optional 한 부분)

시작줄 & 헤더블록 → 줄 단위로 분리된 아스키 문자열
(각 줄은 캐리지리턴(ACSII 13) & 개행문자(ACSII 10)로 구성된 두 글자의 줄바꿈 문자열(CRLF)로 끝난다)

본문 → 시작줄, 헤더블록과 달리 본문은 텍스트와 이진데이터(ex) 이미지나 동영상)를 포함할 수 있고, 그냥 비어있을 수도 있음

2.1 메시지 문법

모든 HTTP 메시지

• 요청: 웹 서버에 어떤 동작을 요구

• 응답: 요청의 수행 결과를 클라이언트에게 돌려줌 (상태정보와 결과 데이터 등)

  ⇒ 둘다 기본적 구조가 같음!

요청/응답 메시지 형식

• 요청

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

<엔터티 본문>

• 응답

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

<엔터티 본문>

2.2 시작줄

요청: <메서드> <요청 URL> <버전>  (공백으로 구분)

• 서버에게 리소스에 대해 무언가를 해달라고 부탁
• 메서드: 클라이언트 측에서 서버가 리소스에 대해 수행해주기 바라는 동작 (어떤 동작이 일어나야 하는지 설명해주는 메서드)

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

  (리소스를 가리키는 절대 경로이기만 하면 대체로 문제 x, ex) /item/list.txt )

• 버전: 이 메시지에서 사용중인 HTTP의 버전

  형식: HTTP/<메이저>.<마이너> → ex) HTTP/1.0

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

• 수행 결과에 대한 상태 정보와 결과데이터를 클라이언트에게 돌려준다

• 상태코드: 요청중에 무엇이 일어났는지 설명하는 세자리 숫자, 각코드의 첫번째 자리수는 상태의 일반적인 분류(성공, 에러 등)를 나타낸다.

  대표적인 상태코드: 200(OK), 401(Unauthorized), 404(Not Found)

• 사유구절: 숫자로된 상태코드를 사람이 이해할 수 있게 설명해주는 짧은 문구 (단지 이 목적뿐)

2.3 헤더

• 시작줄 다음으로 0개, 1개 또는 여러개의 헤더들, 해더의 목록은 빈줄(CRLF)로 끝나 헤더 목록의 끝과 엔터티 본문의 시작을 표시한다.

• HTTP 헤더필드: 요청 & 응댭 메시지에 추가정보를 더한다. (이름/값 쌍의 목록)

• HTTP/1.1 과 같은 몇몇 버전의 HTTP는 요청이나 응답에 어떤 특정 헤더가 포함되어야만 유효한 것으로 간주

• 헤더 분류:
  - 일반 헤더: 요청 & 응답 양쪽 모두에 나타낼 수 있음
  - 요청 헤더: 요청에 대한 부가정보 제공
  - 응답 헤더: 응답에 대한 부가정보 제공
  - Entity 헤더: 본문 크기 & 콘텐츠, 리소스 그 자체를 서술
  - 확장 헤더: 명세에 정의되지 않은 새로운 헤더

• 헤더의 간단한 문법: 이름, 콜론(:), 선택적인 공백, 필드값, CRLF(빈줄)가 순서대로 나타난다.

2.4 엔티티 본문

• optional, 메시지의 화물 (이것들을 HTTP가 수송하도록 설계된 것)
• 이미지, 비디오, HTML 문서, SW 어플리케이션, 신용카드 트랜잭션, 전자 우편 등 여러 종류의 디지털 데이터를 실어나를 수 있다

2.5 버전 0.9 메시지

HTTP 버전 0.9는 HTTP 프로토콜의 초기버전으로 오늘날 HTTP 요청, 응답 보다 훨씬 단순하다

• 요청: 메서드, 요청 URL
• 응답: 앤터티 (상태코드, 사유구절 x)

---

3. 메서드

3.1. 안전한 메서드

안전한 메서드란 HTTP 요청결과 서버에 어떤 작용도 없는 메서드로 GET이나 HEAD와 같은 메서드를 말한다.

• 작용이 없다는 것은 HTTP 요청 결과로 인해 서버에서 일어나는 일은 아무것도 없다는 것이다. (ex) 어떤 웹사이트에서 구매를 한 경우 신용카드 대금이 청구되는데 이는 작용이 있는것이다)

3.2. GET

가장 흔히 쓰이는 메서드로 주로 서버에게 리소스를 달라고 요청하기 위해 쓰인다

3.3 HEAD

HEAD메서드는 정확히 GET처럼 행동하지만, 서버는 응답으로 헤더만을 돌려준다. 즉, 엔티티 본문은 반환되지 않는다.

HEAD는 리소스가 아닌 헤더에 대한 정보(ex) 문서 타입) 등이 궁금할 때 사용된다. 또는 응답의 상태코드를 통해 개체의 존재 유무를 확인할 수도 있다.

3.4 PUT

GET 메서드가 서버로부터 문서를 읽어 들이는데 반해 PUT 메서드는 서버에 문서를 쓴다.
어떤 발행 시스템은 사용자가 PUT을 이용해 웹페이지를 만들고 웹서버에 직접 게시할 수 있도록 해준다.

PUT 메서드의 의미는, 서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 이미 URL이 존재한다면 본문을 사용해서 교체하는 것이다. PUT은 콘텐츠를 변경할 수 있게 해주기 때문에, 많은 웹 서버가 PUT을 수행하기 전에 로그인과 같은 사용자 인증을 거친다

3.5 POST

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

(POST - 서버에 데이터를 보내기 위해 사용, PUT - 서버에 있는 리소스(ex) 파일)에 데이터를 입력하기 위해 사용)

3.6 TRACE

클라이언트가 어떤 요청을 할 때, 그 요청은 방화벽, 프락시, 게이트웨이 등의 애플리케이션을 통과할 수 있다. 이들에게는 원래의 HTTP 요청을 수정할 수 있는 기회가 있는데, TRACE 메서드는 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려준다.

• TRACE는 주로 진단을 위해 사용된다 (ex) 요청이 의도한 요청/응답 연쇄를 거쳐가는지 검사)

3.7 OPTIONS

OPTIONS 메서드는 웹 서버에게 여러가지 종류의 지원 범위에 대해 물어본다. 서버에게 특정 리소스에 대해 어떤 메서드가 지원되는지 물어볼 수 있다. (ex) 응답 메시지: 'Allow: GET, PUT, POST')

3.8 DELETE

DELETE 메서드는 서버에게 요청 URL로 지정한 리소스를 삭제할 것을 요청한다.
(그러나 클라이언트는 삭제가 수행되는 것을 보장하지 못한다. 왜냐하면 HTTP 명세는 서버 클라이언트에게 알리지 않고 요청을 무시하는 것을 허용하기 때문이다.)

상태코드

---

참고자료

HTTP 완벽가이드