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

현주·2023년 10월 20일

HTTP 완벽 가이드

목록 보기

3/5

✏️ HTTP 메시지

HTTP 애플리케이션 간에 주고받은 데이터의 블록들
클라이언트, 서버, 프락시 사이를 흐름

✔ 특징

메시지는 원 서버 방향을 인바운드로 하여 송신됨
- 인바운드
  클라이언트 ➜ 서버 방향
  ㅤ
- 아웃바운드
  서버 ➜ 클라이언트 방향 (사용자 에이전트로 돌아오는 것)
모든 메시지는 다운스트림으로 흐름
( 메시지의 발송자는 수신자의 업스트림 )

Ex. 클라이언트와 서버 사이에 프락시 1,2가 순서대로 존재한다고 하면,
요청에서 프락시 1은 프락시 2의 업스트림이고,
응답에서 프락시 2는 프락시 1의 업스트림임
메시지는 시작줄, 헤더 블록, 본문 세 부분으로 나뉨
1. 시작줄
- 요청 메시지 -> 서버에게 리소스에 대해 무엇을 해야하는지 설명
- 응답 메시지 -> 무슨 일이 일어났는지 서술
  ㅤ
1. 헤더 블록
- 속성
  ㅤ
1. 본문
- 데이터 ( 아예 없을 수도 있음 )

✔ 메시지 문법

모든 메시지는 요청 / 응답으로 분류됨

✔️ 요청 메시지

명령과 URL을 포함

<메서드> <요청 URL> <버전> // 여기 모든 필드들은 공백으로 구분
<헤더>

<엔티티 본문>

✔️ 응답 메시지

트랜잭션의 결과를 포함

<버전> <상태코드> <사유 구절> // 여기 모든 필드들은 공백으로 구분
<헤더>

<엔티티 본문>

✏️ 메서드

클라이언트 측에서 서버가 리소스에 대해 수행해주길 바라는 동작

✔️ GET

서버에게 리소스를 달라고 요청

✔️ HEAD

GET 처럼 행동하지만, 서버는 응답으로 본문 없이 헤더만 돌려줌
리소스를 가져오지 않고 개체가 존재하는지, 헤더를 통해 리소스가 변경되었는지, 타입이 무엇인지 등을 알 수 있음

✔️ PUT

서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 이미 URL이 존재한다면 본문을 사용해 콘텐츠 변경

✔️ POST
➜ 서버에 입력 데이터를 전송

✔️ TRACE

자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려줌
Ex. 만약 어떤 요청이 프락시를 거친다면,
중간에 어떤 프락시를 통해 지나가는지 아래와같이 표시되어 서버에게 전달될 것
```
via: 1.1 proxy3.company.com
```
목적지 서버에서 루프백(loopback) 진단을 시작하여, 서버가 자신이 받은 요청 메시지를 본문에 넣어 TRACE 응답을 돌려줌
주로 진단을 위해 사용

Ex. 요청이 의도한 요청/응답 연쇄를 거쳐가는지 검사하거나 프락시나 다른 애플리케이션들이 요청에 어떤 영향을 미치는지 확인할 때

✔️ OPTIONS

특정 리소스에 대해 어떤 메서드가 지원되는지 물어볼 수 있음
서버는 자신의 리소스에 대해 지원하는 메서드의 목록을 반환
실제로 접근하지 않고도 그것에 어떻게 접근하는 것이 최선인지 확인할 수 있는 수단을 제공
Ex.
- 요청메시지
```
OPTIONS * HTTP/1.1
Host: www.hjjju.com
Accept: *
```
- 응답 메시지
```
HTTP/1.1 200 OK
Allow: GET, POST, PUT, OPTIONS
Context-length: 0
```

✔️ DELETE

리소스 삭제 요청

✔️ 확장 메서드

HTTP/1.1 명세에 정의되지 않은 메서드
Ex.
- LOCK - 사용자가 리소스를 잠글 수 있게 함
- MKCOL - 사용자가 문서를 생성할 수 있게 함
- COPY - 서버에 있는 리소스를 복사
- MOVE - 서버에 있는 리소스를 옮김

✔️ 안전한 메서드 ( Safe Method )

HTTP 요청의 결과로 서버에 어떤 작용도 없는 메서드
( 작용이 없다 == HTTP 요청의 결과로 인해 서버에서 일어나는 일이 아무것도 없다 )

GET / HEAD 메서드
ㅤ
But, 무조건 서버에 작용을 유발하지 않는다는 보장은 없고,
( 개발자에 달려있음 )
안전한 메서드의 목적은 서버에 어떤 영향을 줄 수 있는 안전하지 않은 메서드가 사용될 때 사용자들에게 그 사실을 알려주는 HTTP 애플리케이션을 만들 수 있도록 하는 것에 있음

✏️ 요청 URL

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

✏️ 버전

자신이 따르는 프로토콜의 버전
HTTP/<메이저><마이너>
( 메이저와 마이너는 모두 정수 )
버전 번호는 해당 애플리케이션이 지원하는 가장 높은 HTTP 버전을 가리킴

Ex. HTTP/1.0 애플리케이션이 버전 번호가 HTTP/1.1로 된 응답을 받았을 때,
이는 HTTP/1.1 메시지라는 의미가 아니라,
응답을 보낸 애플리케이션이 HTTP/1.1까지 이해할 수 있음을 의미

✏️ 상태코드

요청 중에 무엇이 일어났는지 설명하는 세자리 숫자

✔ 종류

100 ~ 199 - 정보성 상태 코드
200 ~ 299 - 성공 상태 코드
300 ~ 399 - 리다이렉션 상태 코드
( 리소스가 옮겨졌음을 의미 )
400 ~ 499 - 클라이언트 에러 상태 코드
( 클라이언트가 뭔가 잘못된 요청을 했음을 의미 )
500 ~ 599 - 서버 에러 상태 코드
( 서버에서 뭔가 실패했음을 의미 )

✔️ 혼란스러운 100 Countinue 상태코드
이는 요청의 시작 부분 일부가 받아들여졌으며 클라이언트는 나머지를 계속 이어서 보내야함을 의미하는데, 약간의 혼란이 있을 수 있음

클라이언트와 100 Countinue
만약 클라이언트가 엔티티를 서버에게 보내려고 하는데, 그 전에 100 Countinue 응답을 기다린다고 하면,
클라이언트는 서버에게 100 Countinue로 하는 Expect 요청 헤더를 보낼 필요가 있음
그러나 서버의 100 Countinue 응답을 마냥 기다리기만 하면 안되고,
약간의 타임아웃 후에 그냥 엔티티를 보내야 함
ㅤ

서버와 100 Continue
만약 서버가 100 Continue 값이 담긴 Expect 헤더가 포함된 요청을 받는다면, 100 Continue 응답 혹은 에러 코드로 답해야함
( 무조건 100 Countinue로 하는 Expect 요청 보낸 클라이언트 한테만 100 Continue 응답 가능 )
그런데 이 응답 보내기 전에 클라이언트로부터 엔티티의 일부나 전체가 도착했다면, 서버는 이 코드를 보낼 필요가 없음
( 클라이언트는 이미 계속 보내기로 결정했기 때문 )
따라서 이 경우에는 100 Continue 응답은 생략 후 해당 요청에 대한 응답만 보내면 됨
ㅤ

프락시와 100 Countinue
프락시가 클라이언트로부터 100 Countinue 응답을 유도한 요청을 받는다면,
요청을 전달해야할 서버의 버전에 따라 대응이 다른데,
만약 홉 서버가 HTTP/1.1 을 따르거나 어떤 버전을 따르는지 모른다면, Expect 헤더를 포함시켜 서버에게 요청을 전달해야하고,
홉 서버가 1.1보다 이전 버전의 HTTP를 따르는 것을 안다면, 프락시는 417 Expectation Failed 에러로 응답해야함

✏️ 사유 구절 (reason-phrase)

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

Ex. HTTP/1.0 200 OK 에서 사유구절은 OK

✏️ 헤더들

이름, 콜론(;), 공백(없어도 됨), 값, CRLF(빈줄)가 순서대로 나타남
헤더의 목록은 꼭 CRLF로 끝나 헤더 목록의 끝과 엔티티 본문의 시작을 표시함
긴 헤더는 줄 앞에 최소 하나의 스페이스 혹은 탭을 두고 여러 줄로 쪼개어 적어도 됨

✔ 헤더 분류

일반 헤더 ( General Headers )
➜ 요청과 응답 양쪽에 모두 나타낼 수 있는 헤더

Ex. Date 헤더
( 메시지가 만들어진 일시를 지칭 )
요청 헤더 ( Request Headers )
➜ 요청에 대한 부가 정보를 제공하는 헤더

Ex. Accept 헤더
( 서버에게 클라이언트가 자신의 요청에 대응하는 어떤 미디어 타입도 받아들일 것임을 의미 )
응답 헤더 ( Response Headers )
➜ 응답에 대한 부가 정보를 제공하는 헤더
Entity 헤더 ( Entity Headers )
➜ 본문 크기와 콘텐츠, 혹은 리소스 그 자체를 서술하는 헤더

Ex. Content-Type 헤더
( 보내는 자원의 형식을 명시하기 위해 헤더에 실리는 정보 )
확장 헤더 ( Extension Headers )
➜ 애플리케이션 개발자들에 의해 만들어졌지만 아직 승인된 HTTP 명세에는 추가되지 않은 비표준 헤더