[3장] HTTP 메시지(1)

cdwde·2022년 7월 26일

HTTP 완벽 가이드

목록 보기

3/6

메시지의 흐름

HTTP 메시지는 HTTP 애플리케이션 간에 주고 받은 데이터의 블록
인바운드, 아웃바운드, 업스트림, 다운스트림은 메시지의 방향 의미

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

HTTP는 인바운드, 아웃바운드라는 용어를 트랜잭션 방향을 표현하기 위해 사용

메시지가 원 서버로 향하는 것이 인바운드로 이동하는 것
모든 처리가 끝난 뒤에 메시지가 사용자 에이전트로 돌아오는 것이 아웃바운드로 이동하는 것

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

요청 메시지, 응답 메시지에 관계없이 모든 메시지는 다운스트림으로 흐름
메시지의 발송자는 수신자의 업스트림

메시지의 각 부분

각 메시지는 클라이언트로부터의 요청이나 서버로부터의 응답 중 하나 포함
시작줄은 어떤 메시지인지 서술, 헤더 블록은 속성 담고 있음, 본문은 데이터 담고 있음
시작줄과 헤더는 줄 단위로 분리된 아스키 문자열로 각 줄은 캐리지 리턴과 개행 문자로 구성된 두 글자의 줄바꿈 문자열(CRLF)로 끝남
본문은 텍스트나 이진데이터를 포함할 수도, 비어있을 수도 있음

메시지 문법

메서드: 클라이언트 측에서 서버가 리소스에 대해 수행해주길 바라는 동작
요청 URL: 요청 대상이 되는 리소스를 지칭하는 완전한 URL 혹은 URL의 경로 구성 요소
(URL의 경로 구성요소라고 해도, 클라이언트가 서버와 직접 대화하고 있고 경로 구성요소가 리소스를 가리키는 절대 경로기만 하면 문제 없음)
버전: 사용중인 HTTP의 버전
상태코드: 요청 중 무엇이 일어났는지 설명하는 세 자리 숫자
사유 구절(reason-phrase): 상태 코드를 사람이 이해할 수 있게 설명해주는 짧은 문구
상태 코드 이후부터 줄바꿈 문자열까지
ex) HTTP/1.0 200 NOT OK
헤더들: 이름, 콜론, 선택적인 공백, 값, CRLF가 순서대로 나타나는 0개 이상의 헤더들
엔티티 본문: 모든 메시지가 엔티티 본문을 갖는 것은 아니므로 때때로 메시지는 그냥 CRLF로 끝남

헤더나 엔티티 본문이 없더라도 HTTP 헤더의 집합은 항상 빈 줄(CRLF)로 끝남

시작줄

요청 메시지의 시작줄은 무엇을 해야하는지, 응답 메시지의 시작줄은 무슨 일이 일어났는지 말함

요청줄

서버에서 어떤 동작이 일어나야 하는지 설명해주는 메서드, 그 동작에 대한 대상을 지칭하는 요청 URL, 클라이언트가 어떤 HTTP 버전으로 말하고 있는지 서버에게 알려주는 HTTP 버전이 공백으로 구분
(a) 그림에서 요청 메서드는 GET, 요청 URL은 /test/hi-there.txt, 버전은 HTTP/1.1

응답줄

수행 결과에 때한 상태 정보와 결과 데이터를 클라이언트에게 돌려줌
응답 메시지에서 쓰인 HTTP 버전, 상태코드, 수행 상태에 대해 설명해주는 텍스트로 된 사유구절이 공백으로 구분
(b)그림에서 HTTP 버전은 HTTP/1.0, 상태코드는 200, 사유구절은 OK
(HTTP/1.0이전 시절에는 응답에 응답줄이 들어있을 필요 없었음)

메서드

서버에게 무엇을 해야하는지 말해줌
HTTP 명세는 공통 요청 메서드의 집합을 정의
추가 메서드는 HTTP 명세를 확장하는것 = 확장 메서드

메서드	설명	메시지 본문 여부
GET	서버에서 어떤 문서를 가져옴	없음
HEAD	서버에서 어던 문서에 대해 헤더만 가져옴	없음
POST	서버가 처리해야 할 데이터 보냄	있음
PUT	서버에 요청 메시지의 본문 저장	있음
TRACE	메시지가 프락시를 거쳐 서버에 도달하는 과정 추적	없음
OPTIONS	서버가 어떤 메서드를 수행할 수 있는지 확인	없음
DELETE	서버에서 문서 제거	없음

상태코드

클라이언트에게 무엇이 일어났는지 말해줌

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

사유구절

상태 코드에 대한 글로 된 설명 제공

버전 번호

HTTP/x.y 형식으로 요청과 응답 메시지 양쪽 모두에 기술
자신이 따르는 프로토콜의 버전을 상대방에게 말해주기 위한 수단
애플리케이션이 지원하는 가장 높은 HTTP 버전
(응답의 프로토콜 버전이 HTTP/1.1이라는 것은 응답을 보낸 애플리케이션이 HTTP/1.1까지 이해할 수 있음을 의미)

헤더

일반 헤더: 요청과 응답 양쪽에 모두 나타날 수 있음
요청 헤더: 요청에 대한 부가 정보 제공
응답 헤더: 응답에 대한 부가 정보 제공
Entity 헤더: 본문 크기와 콘텐츠, 리소스 자체 서술
확장 헤더: 명세에 정의되지 않은 새로운 헤더
긴 헤더의 경우 여러 줄로 쪼갤 수 있는데 앞에 최소 하나의 스페이스 혹은 탭 문자 필요

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

버전 0.9 메시지

요청은 메서드와 요청 URL, 응답은 엔티티로만 구성
버전 정보, 상태코드, 사유구절 없음

메서드

안전한 메서드

GET, HEAD 메서드는 HTTP 요청의 결과로 서버에 어떤 작용도 없기에(=요청의 결과로 인해 서버에서 일어나는 일이 없음) 안전한 메서드
서버에 어떤 영향을 줄 수 있는 안전하지 않은 메서드가 사용될 때 사용자들에게 그 사실을 알려주는 HTTP 애플리케이션을 만들 수 있는 것에 목적

GET

서버에게 리소스를 달라고 요청하기 위해 사용

HEAD

GET처럼 행동하지만 서버는 응답으로 헤더만 돌려줌, 엔티티 본문 반환X
클라이언트가 리소스를 실제로 가져올 필요 없이 헤더만을 조사할 수 있게 해줌
사용 시

리소스를 가져오지 않고도 그에 대해 무엇인가를 알 수 있음
응답의 상태 코드를 통해 개체가 존재하는지 확인 가능
헤더를 확인해 리소스가 변경되었는지 검사할 수 있음

반환되는 헤더가 GET으로 얻는 것과 정확히 일치함을 보장해야 함
HTTP/1.1 준수를 위해서는 HEAD 메서드가 반드시 구현되어 있어야 함

PUT

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

POST

서버에 입력 데이터를 전송하기 위해 설계
HTML 폼을 지원하기 위해 흔히 사용
채워진 폼에 담긴 데이터는 서버로 전송, 서버는 이를 모아 필요로 하는 곳에 보냄

TRACE

클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이는지 알려줌
목적지 서버에서 루프백(loopback) 진단 시작하고, 요청 전송의 마지막 단계에 있는 서버는 자신이 받은 요청 메시지를 본문에 넣어 TRACE 응답을 돌려줌
클라이언트는 자신과 목적지 서버 사이에 있는 모든 HTTP 애플리케이션의 요청/응답 연쇄를 따라가면서 자신이 보낸 메시지가 망가졌거나 수정되었는지, 어떻게 변경되었는지 확인할 수 있음
프락시나 다른 애플리케이션들이 요청에 어떤 영향을 미치는지 확인할 때 좋은 도구
중간 애플리케이션이 여러 다른 종류의 요청(각각 다른 메서드를 사용한)들을 일관되게 다룬다고 가정하는게 문제
TRACE 응답의 엔티티 본문에는 서버가 받은 요청 그대로 들어있음