[HTTP] HTTP 메시지는 어떤내용을 주고 받는가?

dev stefanCho·2022년 2월 28일
0

http-definition-guide

목록 보기
2/3

HTTP 메시지 흐름

어떤 방향으로 흐르는가?

메시지는 one direction으로 inbound하여 송신됩니다.
그리도 down-stream으로 흐르게 됩니다.

쉽게 말해서 아래와 같이 한쪽방향으로만 흐른다는 의미입니다.
(클라이언트 -> 프록시 -> 서버 -> 프록시 -> 클라이언트)

요청과 응답

클라이언트에서 서버로 데이터를 보내는것을 요청(Request)
서버에서 클라이언트로 데이터를 보내는것을 응답(Response)라고 합니다.

이 요청과 응답은 시작줄, 헤더, 엔터티 본문으로 구성됩니다.
그리고 시작줄, 헤더, 엔터티는 줄바꿈(CRLF, Carraige Return Line Feed)로 구분됩니다.

시작줄이나 헤더와는 달리, 본문은 비어있거나, 텍스트나 binary 데이터를 포함할 수도 있습니다.

요청메시지


요청메시지 형식은 다음과 같습니다.

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

<엔터티 본문>

맨첫번째 줄은 요청줄이라고 하고, 공백으로 구분됩니다.
요청줄은 서버에 어떤 동작이 일어나야하는지 설명해주는 역할을 합니다.

메서드

클라이언트 측에서 서버가 리소스에 대해 수행해주길 바라는 동작입니다. (GET, POST, PUT 등 한단어로 되어있음)

  • GET
    • 서버에서 문서를 가져옴
  • HEAD
    • 서버에서 어떤문서에 대한 헤더(Header)만 가져옴, 엔티티 본문은 결코 반환하지 않음
    • 주로 리소스타입이나 데이터 개체 존재유무, 변경여부 등을 파악하기 위해서 사용함
    • 반환되는 헤더는 반드시 GET과 일치해야함 (서버에서 이것을 보장해줘야 합니다.)
  • POST
    • 서버가 처리해야 할 데이터를 보냄
    • 요청본문을 가지고 요청 URL의 이름대로 새문서를 만들거나, 이미 URL이 있다면 본문을 교체
  • PUT
    • 서버에 요청메시지 본문을 저장함
    • 입력데이터를 전송하기 위해서 설계되었음 (주로 HTML 폼을 지원하기 위해서 흔히 사용됨)
  • TRACE
    • 메시지가 프락시를 거쳐 서버에 도달하는 과정을 추적
    • 주로 진단을 위해서 사용됨
    • TRACE 요청은 어떠한 엔터티 본문도 보낼 수 없음
  • OPTIONS
    • 서버가 어떤 메서드를 수정할 수 있는 지 확인
    • 응답에 Allow 헤더로 사용가능한 메서드를 알려줌
    • 리소스에는 실제로 접근하지 않고, 어떻게 접근하는게 최선인지 확인할 수 있는 수단을 클라이언트에게 제공하는 것
  • DELETE
    • 서버에서 문서를 제거
    • 클라이언트에서 DELETE 요청을 보내는 것이, 꼭 삭제를 보장하는 것은 아닙니다. 왜냐하면 HTTP 명세는 서버가 클라이언트에게 알리지 않으면서 요청을 무시하는 것을 허용하기 때문입니다.

여기에서 GET, HEAD 같은 메서드는 안전한 메서드(Safe Method)라고 부릅니다. GET이나 HEAD 메서드를 사용하는 HTTP 요청의 결과로 서버에 어떤 작용도 없기 때문입니다.

요청 URL

리소스를 가리키는 url입니다.

버전

사용중인 HTTP 버전입니다.

HTTP/<메이저>.<마이너>

HTTP 애플리케이션들이 자신이 따르는 프로토콜의 버전을 상대방에게 말해주기 위한 수단입니다.
응답의 버전정보가 HTTP/1.1이라면 이것은 응답이 HTTP/1.1까지 이해할 수 있음을 의미합니다. (응답자체가 HTTP/1.1 메시지라는 의미가 아닙니다.)
예를 들어 HTTP/1.0으로 요청을 보내고 HTTP/1.1으로 응답을 받을 수도 있습니다.
응답버전의 버전의 숫자를 comma(.) 기준으로 분리된 것으로 봅니다.
예를 들어 HTTP/1.3는 HTTP/1.22보다 낮은 버전입니다. 3과 22를 비교하기 때문에 22가 더 큰 숫자입니다.

헤더

이름, 콜론(:), 선택적 공백, 값, CRLF가 순서대로 나타나는 0개 이상의 헤더입니다.
길이가 너무 긴 경우 줄바꿈을 할 수 있는데 이때는 반드시, 최소 1개의 Tab이나 Space가 있어야합니다.

HTTP/1.0 200 OK
Content-Type: image/gif
Content-Length: 8572
Server: Test Server
	Version 1.0

Server헤더의 값은 "Test Server Version 1.0"이 됩니다.
헤더는 크게 4가지로 분류할 수 있습니다.

일반헤더 (General Headers)

  • 클라이언트, 서버 양쪽 모두에서 사용됨 (다양한 목적으로 사용될 수 있음)
  • 예를 들어 Date는 일반 목적 헤더입니다.

요청헤더 (Request Headers)

  • 요청메시지를 위한 헤더
  • Ex.1) Accept 관련(Accept, Accept-Language 등) Header들은 서버에게 자신이 무엇을 원하고 할수 있는지, 원치 않는 지 알려줄 수 있습니다.
  • Ex.2) 요청 보안헤더로는 Authorization, Cookie와 같은 것이 있습니다.
  • Ex.3) Host, From, User-Agent, If-Modified-Since 등과 같은 요청정보헤더, 조건부 헤더 등이 있습니다.

응답헤더 (Response Headers)

  • 클라이언트에게 부가정보를 제공하는 서버응답 헤더입니다.
  • Ex) Retry-After, Set-Cookie, WWW-Authenticate, Proxy-Authenticate 등이 있습니다.

엔터티헤더 (Entity Headers)

  • HTTP 메시지의 엔터티를 설명하는 헤더들 입니다.
  • 요청, 응답 모두에 나타날 수 있습니다.
  • Allow, Location, Content관련(Content-Type, Content-Language, Content-Length 등), Last-Modified, Expires(캐싱 관련)등이 있습니다.

엔터티 본문

엔터티는 메시지 화물이라고 생각할 수 있습니다. HTTP 메시지는 이미지, 비디오, HTML문서, 소프트웨어 어플리케이션 등 여러 종류의 디지털 데이터를 실어 나를 수 있습니다.
임의의 데이터 블록을 포함합니다. 엔터티 본문이 없더라도 HTTP 헤더의 집합은 항상 CRLF로 끝나야 합니다.
(간혹 이런규칙을 지키지 않은 구현체와 호환을 위해서 마지막 CRLF가 없더라도 메시지를 받아들일 수는 있어야합니다.)

응답메시지


응답메시지 형식은 다음과 같습니다.

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

<엔터티 본문>

맨첫번째 줄은 응답줄이라고 합니다. 모든필드는 공백으로 구분합니다.
수행결과에 대한 상태정보와 결과데이터를 클라이언트에게 돌려주는 역할을 합니다.

상태코드

요청중에 어떤일이 발생했는지 클라이언트에게 설명하는 숫자(3자리)코드입니다. 첫번째 자릿수는 일반적인 분류를 의미합니다.
(상태코드에 대한것은 MDN에 상당히 잘 정리되어 있으므로 따로 정리하지 않겠습니다.)

사유구절(reason-phrase)

사유구절은 오직 사람이 읽기 위한것입니다.
따라서 아래 2개는 사유구절이 전혀 다르지만, 동일하게 성공을 의미하는 것으로 처리되어야 합니다.

HTTP/1.0 200 NOT OK
HTTP/1.0 200 OK

HTTP 명세는 사유 구절에 대한 어떤 엄격한 규칙도 제공하지 않습니다.

profile
Front-end Developer

0개의 댓글