3. HTTP Message

3장 목표. HTTP Message를 어떻게 만들고 이해하는지 배울 수 있다. HTTP: 인터넷 배달원. HTTP Message: 무언가 담아 보내는 소포.

01) 메시지의 흐름

HTTP 메세지란, HTTP 애플리케이션간에 주고받은 데이터 블록들이다.

데이터의 블록들은 메시지 내용과 의미를 설명하는 텍스트 메타 정보로 시작하고, 선택적으로 데이터가 올 수 있다.

클라이언트 - 프록시 - 서버 사이를 흐른다.

메세지 방향 용어: '인바운드', '아웃바운드', '업스트림', '다운스트림'

1

① 인바운드: 원 서버로 향하는 것.

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

③ 다운스트림: 요청/응답 메세지에 관계없이 메시지는 다운스트림으로 흐른다.

④ 업스트림: 발송자는 수신자의 업스트림이다.

[업스트림, 다운스트림은 발송자,수신자에 대한 용어]

02) 메세지 각 부분

2

<요청과 응답 메세지 예>

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

각 메세지는 클라이언트로부터의 요청메세지 또는 서버로 부터의 응답메세지 둘 중 하나를 포함한다. 메세지는 [시작줄 | 헤더 | 본문] 세 부분으로 이루어진다.

​ 시작줄: 어떤 메세지 인지 서술

​ 헤더: 속성

​ 본문: 데이터를 담고 있고 없을 수도 있다.

'시작줄'과 '헤더'는 줄단위로 분리된 아스키 문자열이며, 각 줄은 캐리지 리턴(Carriage return, CR), 개행문자(Line Feed, LF)로 구성된 두글자의 줄바꿈 문자열(= 'CRLF')로 끝난다.

'본문'은 단순히 선택적인 데이터 덩어리이다. '시작줄'이나 '헤더'와 달리 텍스트나 이진 데이터를 포함할 수도 있고 비어있을 수도 있다.

① 메시지 문법

모든 HTTP 메시지는 요청 메시지| 응답 메시지로 분류된다 기본적으로 구조가 같고, 응답메시지는 요청메시지와 시작줄에서만 차이가 있다는 점에 주목.

3

요청메시지, 응답메시지 예

• 메서드: 클라이언트측에서 서버가 리소스에 대해 수행해주길 바라는 동작. 'GET', 'POST', 'HEAD', ...

• 요청 url: 완전한 혹은 url의 경로 구성 요소(2장에서 배운 url 문법에 따라 요청)

• 버전: 메시지에서 사용중인 HTTP 버전 HTTP/<메이저버전>.<마이너버전>

• 상태코드: 요청 중 무슨일이 일어났는지 설명하는 세자리 숫자로, 첫번째 자릿수가 일반적인 분류를 나타낸다.

• 사유구절: 상태코드를 사람이 이해하기위해 설명한 짧은 문구. 오로지 사람에 읽히기 위한 목적으로 존재.

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

• 엔터티 본문: 임의의 데이터 블록을 포함. 헤더나 엔터티 본문이 없더라도, 헤더의 집합은 항상 빈줄로 끝나야한다. (CRLF) . 하지만 실수로 빼먹은 경우 호환을 위해 CRLF로 끝나지 않는 메시지도 받아들일 수 있어야함

② 시작줄

모든 HTTP메시지는 시작줄로 시작한다. 요청메시지는 무엇을 해야할지, 응답메시지는 무슨일이 일어났는지 알려준다.

• 요청줄(요청 메시지 시작줄):

  • 요청메시지는 서버에게 리소스에 대해 무언가 해달라고 부탁한다.

  • 예시: GET /test/hi-there.txt HTTP/1.1

    • 서버에서 어떤 동작이 일어나야하는지 설명해주는 메서드 (GET)

    • 그 동작에 대한 대상을 지시하는 요청URL (/test/hi-there)

    • 클라이언트가 어떤 HTTP버전으로 말하는지 서버에 알려주는 HTTP 버전(HTTP/1.1)

  • 각 필드는 공백으로 구분된다.

• 응답줄(응답 메시지 시작줄):

  • 응답 메시지는 수행 결과에 대한 상태정보와 결과 데이터를 클라이언트에 돌려준다.

  • 에시: HTTP/1.1 200 OK

    • HTTP 버전 (HTTP/1.1)

    • 숫자로된 상태 코드(200)

    • 수행상태에 대해 설명해주는 사유구절(ok)

  • 각 필드는 공백으로 구분.

• 메서드

  • 요청의 시작줄은 메서드로 시작하고, 서버에 무엇을 해야할지 알려준다.

  • HTTP명세는 공통 요청 메서드의 집합을 정의한다.

  • 메서드에 따라서 요청메시지에 본문이 있을수도, 없을수도 있다.

  • 자주쓰이는 메서드(7가지): GET, HEAD, POST, PUT, TRACE, OPTION, DELETE

• 상태코드

  

  • 클라이언트에 무슨일이 일어났는지 알려준다. 응답의 시작줄에 위치한다.

  • 세자리 숫자로 된 코드값을 기준으로 묶인다.

  • 정의된 범위 이외에 인식할 수 없는 상태코드(예 515)를 받으면 범주의 일반적인 구성원으로 가정하고 다루어야한다. (⇒ 서버에러로 보고 다루어야한다.)

  • 3xx 리다이렉션 상태코드: 클라이언트에 리소스가 옮겨졌고 어디에 옮겨졌는지 알려준다.

  • 4xx: 서버가 다룰 수 없는 무언가를 보낸 경우.

• 사유구절: 상태코드의 사람이 이해하기 쉬운 버전.

• 버전번호: HTTP/x.y 형식으로 요청, 응답메시지 양쪽 모두 기술.

  자신이 따르는 프로토콜 버전을 상대에 알리고, 대화 상대의 능력과 메시지 형식에 대한 단서를 제공한다.

③ 헤더

시작줄 다음에 0개, 1개 혹은 여러게의 HTTP 헤더가 온다.

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

기본적으로 이름|값 쌍의 목록으로 이루어져있다. (예: Content-length:19 )

• 헤더 분류

  • 일반헤더: 요청, 응답 양쪽에 나타날 수 있음

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

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

  • Entity헤더: 본문크기, 콘텐츠, 리소스 그 자체 서술

  • 확장헤더: 명세에 정의되지 않은 새로운 헤더

• HTTP 헤더 간단한 문법예:

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

  [ 이름:(공백 생략가능) 필드값1, 필드값2 , ... CRLF ]

• 헤더가 길어지면 여러줄로 쪼갤수 있다. 단, 추가 줄 앞에 1개 이상의 스페이스 혹은 탭 문자가 와야한다.

④ 엔터티 본문

엔터티 본문은 HTTP 메시지의 화물이라 할 수 있다.

이미지, 비디오, HTML문서, 소프트웨어 앱, 전자우편 등 여러 종류의 디지털 데이터를 실어 나를수있다.

3) 메서드

① 안전한 메서드(Safe Method)

HTTP는 안전한 메서드라 불리는 메서드 집합을 정의한다.

GET, HEAD는 안전하다 할 수 있는데, 요청의 결과로 서버에 어떠한 작용도 없다는 의미.

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

② GET

• 리소스 조회. 주로 서버에 리소스를 달라고 요청하기 위해 쓰임.

• 서버에 전달하고싶은 데이터는 쿼리를 통해 전달함. (바디로 데이터 전송가능하나 지원 안할 수 있음)

③HEAD

• GET처럼 행동하지만, 서버는 응답으로 헤더만 돌려준다. (엔터티 본문은 결코 반환되지 않는다.)

• 리소스를 가져오지 않고도 그에 대해 무엇인가(타입등)를 알아낼 수 있다.

• 상태코드를 통해 개체의 존재 유무를 확인할 수 있다.

• 리소스 변경 유무를 검사할 수 있다.

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

④PUT

• 서버에 문서를 쓴다.

• 리소스 대체 없으면 새로 생성

• 폴더에 파일을 넣는 원리와 같이, 기존에 파일이 있었으면 덮어씌우고 없으면 새로 생성(완전대체, 덮어씌움)

• 클라이언트쪽에서 리소스를 식별한다.(클라이언트가 리소스의 위치를 알고 URI 지정)

⑤POST

• HTML form에서 흔히 사용된다.

• 서버가 아직 식별하지 않은 새 리소스 생성 (새로운 리소스 생성 및 등록)

• 요청한 데이터를 처리하고 등록한다.

• 바디에 요청할 데이터를 전달한다.

• 단순 데이터 생성, 변경을 넘어서 프로세스 처리

• 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능 수행가능.

  따라서 다른 메서드로 처리하기 어려운 경우에 사용되기도 한다.

  단, GET이 cache 성능은 더 높다.

⑥TRACE

• 목적지 서버에서 '루프백'진단을 시작. 클라이언트~서버 사이의 모든 요청/응답 연쇄를 따라가면서 보낸 메시지가 망가졌는지, 수정됬는지, 어떻게 변경되었는지 확인이 가능하다. 주로 진단을 위해 사용된다.

⑦ OPTIONS

웹 서버에 여러가지 종류의 지원 범위에 대해 물어본다. 특정 리소스에 대해 어떤 메서드가 지원되는지 물어볼수있다.

⑧ DELETE

서버에 요청 URL로 지정한 리소스를 삭제할 것을 요청함. 클라이언트는 삭제가 수행되는것을 보장받지는 않음. HTTP 명세에서는 서버가 클라이언트에 알리지 않고 요청을 무시하는 것을 허용한다.

⑨PATCH

리소스 부분 변경

서버에서 요청을 잘 안받아줄 수 있다 그럴 때 ⇒ PUT으로 대체.