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

HTTP가 인터넷 배달원이라면, HTTP 메시지는 무언가를 담아 보내는 소포와 같다.

이 장에서 배울 것

• 메시지가 어떻게 흘러가는가
• HTTP 메시지의 세 부분 (시작 줄, 헤더, 개체 본문)
• 요청과 응답 메시지의 차이
• 요청 메시지가 지원하는 여러 기능(메서드)들
• 응답 메시지가 반환하는 여러 상태 코드들
• 여러 HTTP 헤더들은 무슨 일을 하는가

---

3.1 메시지의 흐름

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

메시지 방향을 의미하는 용어

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

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

원 서버란?
전 세계에서 동시에 사용 가능한 하나의 서버

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

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

• HTTP 메시지는 강물과 같이(위에서 아래로) 흐른다.
• 요청 메시지냐 응답 메시지냐에 관계없이 모든 메시지는 다운스트림으로 흐른다.
• 메시지의 발송자는 수신자의 업스트림이다.
• 요청에서는 프락시1이 프락시3의 업스트림이지만, 응답에서는 프락시3이 프락시1의 업스트림이다.
  

3.2 메시지의 각 부분

시작 줄은 이것이 어떤 메시지인지 서술하며, 헤더 블록은 속성을, 본문은 데이터를 담고 있다.

시작줄과 헤더는 그냥 줄 단위로 분리된 아스키 문자열이다. 각 줄은 캐리지 리턴(ASCII 13)과 개행 문자(ASCII 10)로 구성된 두 글자의 줄바꿈 문자열로 끝난다. 이 줄바꿈 문자열은 'CRLF'라고 쓴다.

CRLF 란?
Carriage Return (ASCII 13)과 Line Feed (ASCII 10)의 합성어
다음 줄로 넘어가기 위해 커서를 한 줄 아래로 이동 시키고(Line Feed)
가장 앞으로 옮기는 것(Carriage Return)

1) 시작줄

요청줄

• GET /test/hi-there.txt HTTP/1.1
• 메서드 URL HTTP 버전

상태코드

상태 코드는 클라이언트에게 무엇이 일어났는지 말해주며 응답의 시작줄에 위치한다.

• 전체 범위 / 정의된 범위 / 분류
• 100-199 / 100-101 / 정보
• 200-299 / 200-206 / 성공
• 300-399 / 300-305 / 리다이렉션
• 400-499 / 400-415 / 클라이언트 에러
• 500-599 / 500-505 / 서버 에러

많이 쓰이는 코드들
200 OK : 성공! 요청한 데이터는 응답 본문에 들어있다.
401 Unauthorized : 사용자 이름과 비밀번호를 입력해야 한다.
404 Not Found : 서버는 요청한 URL에 해당하는 리소스를 찾지 못했다.

참고
상태 코드 Mozilla

사유 구절

상태 코드에 대한 글로 된 설명을 제공한다.
사유 구절은 상태 코드와 일대일로 대응된다. 상태 코드의 사람이 이해하기 쉬운 버전이다.

2) 헤더

헤더의 예

• Date: Tue, 3 Oct 1997 02:16:93 GMT => 서버가 응답을 만들어 낸 시각
• Content-length: 15040 => 15,040 바이트의 데이터를 포함한 엔터티 본문
• Content-type: image/gif => 엔터티 본문은 GIF 이미지다.
• Accept: image/gif, image/jpeg, text/html: 클라이언트는 GIF, JPEG 이미지와 HTML을 받아들일 수 있다.

3.3 메서드

1) GET

주로 서버에게 리소스를 달라고 요청하기 위해 쓰인다.

2) HEAD

GET과 비슷하지만 서버 응답으로 헤더만을 돌려준다. 엔터티 본문은 결코 반환되지 않는다. 이는 클라이언트가 리소스를 실제로 가져올 필요 없이 헤더만을 조사할 수 있도록 도와준다.

HEAD를 사용하면

• 리소스를 가져오지 않고도 그에 대해 무엇(타입, 길이 등등)인가를 알아낼 수 있다.
• 응답의 상태 코드를 통해, 개체가 존재하는지 확인할 수 있다.
• 헤더를 확인하여 리소스가 변경되었는지 검사할 수 있다.

3) PUT

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

4) POST

POST 메서드는 서버에 입력 데이터를 전송하기 위해 설계되었다. 실제로, HTML FORM을 지원하기 위해 흔히 사용된다.
채워진 FORM에 담긴 데이터는 서버로 전송되며, 서버는 이를 모아서 필요로 하는 곳에 보낸다.

5) TRACE

TRACE 메서드는 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 되는지 알려준다.

6) OPTIONS

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

7) DELETE

서버에게 요청 URL로 지정한 리소스를 삭제할 것을 요청한다.

3.4 상태 코드

상태 코드는 클라이언트에게 그들의 트랜잭션을 이해할 수 있는 쉬운 방법을 제공한다.

1) 100-199: 정보성 상태코드

• 100 Continue
  요청의 시작 부분 일부가 받아들여 졌으며, 클라이언트는 나머지를 계속 이어서 보내야 함을 의미
  이것을 보낸 후, 서버는 반드시 요청을 받아 응답해야 한다.
• 101 Switching Protocols
  클라이언트가 Upgrade 헤더에 나열한 것 중 하나로 서버가 프로토콜을 바꾸었음을 의미한다.

클라이언트와 100 Continue

• 만약 클라이언트가 엔터티를 서버에 보내려 하고, 그 전에 100 Continue 응답을 기다리겠다면, 클라이언트는 값을 100-continue로 하는 Expect 요청 헤더를 보낼 필요가 있다.

  e.g. Expect: 100-continue

• 만약 클라이언트가 엔터티를 보내려 하지 않는다면, Expect 요청 헤더를 보내지 말아야 한다.
• 100-continue는 여러 측면에서 최적화를 위한 것이다.
• 클라이언트 애플리케이션은 100-continue를 서버가 다루거나 사용할 수 없는 큰 용량의 엔터티를 서버에게 보내지 않으려는 목적으로만 사용해야 한다.
• 100-continue 값이 담긴 Expect 헤더를 보낸 클라이언트는 서버가 100 Continue 응답을 보내주기를 막연히 기다리기만 해서는 안 된다. 약간의 타임아웃 후에 클라이언트는 그냥 엔터티를 보내야 한다.
• 프론트엔드 개발자는 예상하지 못한 100 Continue 응답에도 대비해야 한다.

서버와 100 Continue

• 서버가 100-continue 값이 담긴 Expect 헤더가 포함된 요청을 받는다면, 100 Continue 혹은 에러 코드로 답해야 한다.
• 서버는 절대로 100-continue 응답을 받을 것을 의도하지 않은 클라이언트에게 100 Continue 상태 코드를 보내선 안된다.

1. 클라 : Expect: 100-continue 포함 요청 전송!
2. 서버 : 음. 받을 수 있으니 100 Continue 상태 코드를 응답해볼까?
3. 클라 : 에잇, 그냥 계속 엔터티를 전송하자.
4. 서버 : 음? 아직 100 Continue를 보내지 않았는데 엔터티(일부 혹은 전체)가 왔네? 100 코드를 안 보내도 되겠군!
5. 서버 : 요청을 받았으니 그에 대한 응답을 해줘야겠다!

프락시와 100 Continue

Expect: 100-continue 응답을 받은 프록시가 해야할 일

• 다음 홉(next-hop) 서버가 HTTP/1.1을 따르거나 혹은 어떤 버전을 따르는지 모른다면, Expect 헤더를 포함 시켜서 다음으로 전달해야 한다.
• 1.1 보다 이전 버전이라면 417 Expectation Failed 에러로 응답해야 한다.

2) 200-299: 성공 상태 코드

200 OK

• 요청은 정상이고, 엔터티 본문은 요청된 리소스를 포함하고 있다.

201 Created

• 서버 개체를 생성하라는 요청(예:PUT)을 위한 것
• 응답은, 생성된 리소스에 대한 Location 헤더와 함께, 참조 가능한 URL을 엔터티 본문에 포함해야 한다.
• 서버는 상태 코드를 보내기에 앞서 반드시 객체를 생성해야 한다.

202 Accepted

• 요청은 받아들여 졌으나 서버는 아직 그에 대한 어떤 동작도 수행하지 않았다.
• 요청이 받아들이기에 적법해 보인다는 의미일 뿐이다.

203 Non-Authoritative Information

• 엔터티 헤더에 들어있는 정보가 원래 서버가 아닌 리소스의 사본에서 왔다.
• 중개자가 리소스의 사본을 갖고 있었지만 리소스에 대한 메타 정보를 검증하지 못한 경우 발생할 수 있다.

204 No Content

• 응답 메시지는 헤더와 상태 줄을 포함하지만 엔터티 본문은 포함하지 않는다.
• 주로 웹 브라우저를 새 문서로 이동 시키지 않고 갱신하고자 할 때 사용한다.

205 Reset Content

• 주로 브라우저를 위해 사용되는 또 하나의 코드
• 브라우저에게 현재 페이지에 있는 HTML 폼에 채워진 모든 값을 비우라고 말한다.

206 Partial Content

• 부분 혹은 범위 요청이 성공했다.
• 클라이언트가 특별한 헤더를 사용해서 문서의 부분 혹은 특정 범위를 요청할 수 있다.
• Content-Range와 Date 헤더를 반드시 포함

  Content-Range란?
  전체 바디 메시지에 속한 부분 메시지의 위치를 알려줍니다.
  ex) Content-Range: bytes=60-65/298997

• Etag와 Content-Location 중 하나의 헤더도 반드시 포함해야 한다.

  Etag란?
  만약 특정 URL 의 리소스가 변경된다면, 새로운 ETag 가 생성됩니다. ETag 는 지문과 같은 역할을 하면서 다른 서버들이 추적하는 용도에 이용되기도 합니다. ETag 를 비교하여 리소스가 서로 같은지의 여부를 빠르게 판단할 수 있지만, 서버에서 무기한으로 지속될 수 있도록 설정할 수도 있습니다.
  ex) ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

3) 300-399: 리다이렉션 상태 코드

• 클라이언트가 관심있어하는 리소스에 대해 다른 위치를 사용하라고 말해주거나 그 리소스의 내용 대신 다른 대안 응답을 제공한다.
• 만약 리소스가 옮겨졌다면, 클라이언트에게 리소스가 옮겨졌으며 어디에서 찾을 수 있는지 알려주기 위해 리다이렉션 상태 코드와 Location 헤더를 보낼 수 있다.
• 응답을 받은 브라우저는 알아서 새 위치로 이동한다.
• 리다이렉션 상태 코드 중 몇몇 은 요청한 리소스에 대한 로컬 복사본이 서버에 있는 리소스와 비교했을 때 최신인지 확인하기 위해 사용된다.
• 클라이언트는 문서가 1997년 10월 이후에 수정된 경우에만 문서를 가져오기 위해 If-Modified-Since 헤더를 전송한다.
• 문서가 변경되지 않았다면 서버는 리소스 대신 304 상태 코드로 응답한다.

300 Multiple Choices

• 클라이언트가 동시에 여러 리소스를 가리키는 URL을 요청한 경우, 그 리소스의 목록과 함께 반환된다.
• 사용자는 원하는 하나를 선택할 수 있다.

301 Moved Permanently

• 요청한 URL이 옮겨졌을 때 사용한다.
• 응답은 Location 헤더에 현재 리소스가 존재하고 있는 URL을 포함해야 한다.

302 Found

• 301 상태 코드와 같다.
• 클라이언트는 Location 헤더로 주어진 URL을 리소스를 임시키 가리키기 위한 목적으로 사용해야 한다.

303 See Other

• 클라이언트에게 리소스를 다른 URL에서 가져와야 한다고 알려줄 때 쓰인다.
• 새 URL은 응답 메시지의 Location 헤더에 들어있다.
• 주 목적은 POST 요청에 대한 응답으로 클라이언트에게 리소스의 위치를 알려주는 것이다.

304 Not Modified

• 클라이언트가 조건부 요청을 보냈을 때 리소스가 수정되지 않았다면 이 상태 코드를 응답으로 보낸다.
• 이 상태 코드를 동반한 응답은 엔터티 본문을 가져선 안된다.

305 Use Proxy

• 리소스가 반드시 프록시를 통해서 접근되어야 함을 나타내기 위해 사용한다.

307 Temporany Redirect

• 301 상태 코드와 비슷하다.
• 클라이언트는 Location 헤더로 주어진 URL을 리소스를 임시키 가리키기 위한 목적으로 사용해야 한다.

비슷한 302, 303, 307 상태 코드의 차이

1. HTTP/1.0과 HTTP/1.1 애플리케이션이 이 상태 코드를 다루는 방식에 차이 발생
2. 서버는 클라이언트 HTTP 버전을 검사하여 가장 적절한 리다이렉션 응답 상태 코드를 결정
3. HTTP/1.0 클라이언트 POST 요청 -> 302 리다이렉션 상태 코드 -> Location URL을 GET 요청
4. HTTP/1.1 명세는 리다이렉션을 위해 303 상태 코드를 사용
5. 혼란을 막기 위해(?), HTTP/1.1 명세는 HTTP/1.1 클라이언트의 일시적인 리다이렉트를 위해 302 상태 코드 대신 307 상태 코드를 사용하라고 한다.

4) 400-499: 클라이언트 에러 상태 코드

• 서버가 다룰 수 없는 요청이 왔을 때 발생

400 Bad Request

• 클라이언트가 잘못된 요청을 보냈다고 말해준다.

401 Unauthorized

402 Payment Required

403 Foribidden

• 요청이 서버에 의해 거부 되었음을 알려주기 위해 사용된다.
• 거부된 이유를 엔터티 본문을 이용해 설명할 수 있지만, 보통 서버가 그 이유를 숨기고 싶을 때 이 코드를 사용한다.

404 Not Fount

• 서버가 요청한 URL을 찾을 수 없음을 알려주기 위해 사용한다.

500-599: 서버 에러 상태 코드

• 클라이언트가 서버의 제한이 걸린 것일 수도 있고 혹은 게이트웨이 리소스와 같은 서버의 보조 구성 요소에서 발생한 에러일 수도 있다.

500 Internal Server Error

• 서버가 요청을 처리할 수 없게 만드는 에러를 만났을 때 사용한다.

501 Not Implemented

• 클라이언트가 서버의 능력을 넘은 요청을 했을 때 사용한다. (예: 서버가 지원하지 않는 메서드를 사용)

502 Bad Gateway

• 즉 서로 다른 프로토콜을 연결해주는 장치가 잘못된 프로토콜을 연결하거나, 어느 쪽 프로토콜에 문제가 있어 통신이 제대로 되지 않을 때 출력되는 코드
• 서버가 과부하 되었을 경우, 사용자 브라우저에 이상이 있거나 잘못된 네트워크 연결을 했을 경우 발생

3.5 헤더

헤더와 메서드는 클라이언트가 무엇을 하는지 결정하기 위해 함께 사용된다.
헤더에는 특정 종류의 메시지에만 사용할 수 있는 헤더와, 더 일반 목적으로 사용할 수 있는 헤더, 응답과 요청 메시지 양쪽 모두에서 사용하는 헤더가 있다.
크게 다섯 가지로 분류된다.

1) 일반 헤더

• 메시지에 대한 아주 기본적인 정보를 제공한다.

일반 헤더 종류

• Connection
  클라이언트와 서버가 요청/응답 연결에 대한 옵션을 정할 수 있게 해준다.
• Date
  메시지가 언제 만들어졌는지에 대한 날짜와 시간을 제공한다.
• MIME-Version
  발송자가 사용한 MIME 버전을 알려준다.
• Transfer-Encoding
  메시지에 어떤 인코딩이 적용되었는지 말해준다.

2) 요청 헤더

• 요청 메시지에만 의미를 갖는 헤더
• 누가 그 요청을 보냈는지에 대한 정보나 클라이언트의 선호나 능력에 대한 정보를 준다.

요청 헤더 종류

• Client-IP
  클라이언트가 실행된 컴퓨터의 IP를 제공한다.
• From
  클라이언트 사용자의 메일 주소를 제공한다.
• Host
  요청의 대상이 되는 서버의 호스트 명과 포트를 준다.

Accept 관련 헤더

• 클라이언트가 Accept 헤더를 이용해 자신의 선호와 능력을 알려줄 수 있다.
• 서버는 이 정보를 이용해 더 스마트하게 응답을 보낼 수 있다.
• Accept 헤더를 이용해 클라이언트는 자신이 원하는 정보를 얻을 수 있고, 서버는 클라이언트가 사용할 수 없는 것을 전송하는데 시간과 대역폭을 낭비하지 않을 수 있다.

e.g. Accept: */*, Accept: image/jpeg, text/plain

조건부 요청 헤더

• 클라이언트가 요청에 제약을 넣을 때 사용
• 클라이언트가 이미 어떤 문서의 사본을 가지고 있는 상태라면, 서버에게 그 문서를 요청할 때 자신이 갖고 있는 사본과 다를 때만 전송해달라고 요청할 수 있다.

e.g. Expect: 100-continue
: 클라이언트가 요청에 필요한 서버의 행동을 열거할 수 있게 해준다.
e.g. If-Modified-Since: Sat, 06 Aug 2011 00:09:14 GMT
: 주어진 날짜 이후에 리소스가 변경되지 않았다면 요청을 제한한다.

요청 보안 헤더

• HTTP는 자체적으로 요청을 위한 간단한 인증요구/응답 체계를 갖고 있다.
• 클라이언트가 리소스에 접근하기 전에 자신을 인증함으로써 트랜잭션은 좀 더 안전하게 한다.

e.g. Authorization: Basic realm="localhost"
: 클라이언트가 서버에게 제공하는 인증 그 자체에 대한 정보를 담고있다.

프락시 요청 헤더

• 프락시의 기능을 돕기 위한 헤더

3) 응답 헤더

• 응답 메시지에만 의미를 갖는 헤더
• 누가 응답을 보내는지, 응답자의 능력은 어떻게 되는지 등을 제공하며 클라이언트가 응답을 더 잘 다룰 수 있도록 도움을 준다.

협상 헤더

• 어떠한 리소스에 대해 HTTP/1.1은 서버와 클라이언트가 어떤 표현을 가진 리소스를 선택할 것인지 협상한다.

응답 보안 헤더

• HTTP 인증요구/응답 체계에서 응답 측에 해당하는 것이 요청 보안 헤더이고 인증요구에 해당하는 것이 응답 보안 헤더이다.

e.g. Proxy-Authenticate: Basic Yno5eWw1Oldyb25nLmdvLldheSsyNDA=

4) 엔터티 헤더

• 요청과 응답 양쪽 모두 엔터티 헤더를 포함할 수 있다.
• 엔터티 헤더는 메시지의 수신자에게 자신이 다루고 있는 것이 무엇인지 말해준다.

엔터티 헤더 종류

• Allow
  이 엔터티에 대해 수행될 수 있는 요청 메서드들을 나열한다.
• Location
  클라이언트에게 엔터티가 실제로 어디에 위치하고 있는지 말해준다. 수신자에게 리소스에 대한 위치를 알려줄 때 사용한다.

콘텐츠 헤더

• 콘텐츠 헤더는 엔터티의 콘텐츠에 대한 구체적인 정보를 제공한다.
• Content-Encoding
  본문에 적용된 어떤 인코딩
• Content-Language
  본문을 이해하는데 가장 적절한 자연어
• Content-Length
  본문의 길이나 크기
• Content-Location
  리소스가 실제로 어디에 위치하는지
• Content-Range
  전체 리소스에서 이 엔터티가 해당하는 범위르 바이트 단위로 표현
• Content-Type
  이 본문이 어떤 종류의 객체인지

엔터티 캐싱 헤더

• 일반 캐싱 헤더는 언제 어떻게 캐시가 되어야 하는지에 대한 지시자를 제공한다.

  e.g. Cache-Control: public, max-age=31536000
  MDN Cache-Control

• 엔터티 캐싱 헤더는 엔터티 캐싱에 대한 정보를 제공한다.

  e.g. ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
  MDN ETag
  e.g. Expires: Wed, 21 Oct 2015 07:28:00 GMT
  MDN Expires