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

질문

- 메시지가 어떻게 흘러가는가

- HTTP 메시지의 세부분 (시작줄, 헤더, 개체 본문)

- 요청과 응답 메시지 차이

- 요청 메시지가 지원하는 여러 기능(메서드)들

- 응답 메시지가 반환하는 여러 상태 코드들

- 여러 HTTP 헤더들은 무슨일을 하는가

 

3.1 메시지의 흐름

http메시지는 http 어플리케이션 간에 주고받은 데이터 블록들이다.

 

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

메시지가 원 서버로 향하는 것은 인바운드로 향하는것.

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

 

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

HTTP 메시지는 강물과 같이 흐른다. 

요청/응답 메시지에 관계없이 모든 메시지는 다운스트림을 흐른다.

메시지의 발송자는 수신자의 업스트림이다.

 

 

3.2 메시지의 각 부분

HTTP 메시지는 단순한 데이터의 구조화된 블록이라고 할 수 있다.

각 메시지는 클라이언트로부터 요청이나 서버로부터 응답중  하나를 포함한다.

 

메시지는 시작줄/헤더/본문 이렇게 3부분으로 이루어진다.

 

3.2.1 메시지 문법

모든 http 메세지는 요청/응답으로 나뉜다.

요청 메시지는 웹 서버에 어떤 동작을 요구하고, 응답메시지는 요청의 결과를 클라이언트에세 돌려준다.

 

그 둘의 구조는 기본적으로 같다.

- 메서드

- 요청 URL

- 버전 (http의 버전)

- 상태코드

- 사유구절

- 헤더들

엔티티본문

 

3.2.2 시작줄

모든 http 메서드는 시작줄로 시작한다.

요청 메시지의 시작줄은 무엇을 해야하는지 말해주고 응답 메시지의 시작줄은 무슨일이 일어났는지를 말해준다.

 

- 요청줄 (서버에세 리소스에 대해서 무언가를 해달라고 부탁)

- 응답줄 (부탁 수행 결과)

- 메서드 (서버에게 무엇을 해야하는지에 대해서 말해준다.)

    - GET/HEAD/POST/PUT/DELETE/TRACE/OPTIONS

- 상태코드

- 사유구절

- 버전번호

 

 

3.2.3 헤더

시작줄 다음에는 최소 0개의 헤더가 온다.

- 헤더분류 (일반헤더/요청헤더/응답헤더/엔티티헤더/확장헤더)

 

3.2.4 엔티티 본문

선택적인 부분으로 http메시지의 화물이다.

이미지 비디오 html 등등...

 

3.3 메서드

 

3.3.1 안전한 메세드

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

GET, HEAD 메서드는 안전하다고 볼 수 있다.

이것은 GET, HEAD 메서드를 사용하는 것은 HTTP 요청의 결과로 서버에 어떤작용도 없음을 의미한다.

 

3.3.2 GET

가장 흔히 쓰이는 메서드.

서버에게 리소스를 달라고 요청할때 쓰인다.

 

3.3.3 HEAD

정확하게 GET처럼 동작하지만, 서버는 응답으로 헤더만 돌려준다.

엔티티 본문은 절대로 반환되지 않는다.

 

3.3.4 PUT

GET 메서드가 서버로부터 문서를 읽어 들이는데 반해서, PUT 메서드는 서버에 문서를 쓴다.

PUT 메서드의 의미는 서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 이미 URL이 존재한다면 본문을 사용해서 교체하는 것이다.

 

3.3.5 POST

서버에 입력 데이터를 전송하기 위해 설계되었다.

실제로 HTML 폼을 지원하기 위해서 흔히 사용된다.

 

3.3.6 TRACE

주로 진단을 위해 사용된다.

요청이 의도한 요청/응답의 과정을 거치는지, 다른 어플리케이션들이 요청에 어떤 영향을 미치는지 확인해보고자할때 좋은 도구다.

 

진단을 위해 사용할 때는 괜찮지만, 다른 종류의 요청들을 일관되게 다룬다고 가정하는 문제가 있긴하다.

왜냐하면 많은 HTTP 어플리케이션은 메서드에 따라서 다르게 동작한다.

(POST는 프락시가 바로 서버로 전달하는데, GET은 웹 캐시와 같은 다른 HTTP 어플리케이션으로 전송한다.)

반면, TRACE 메서드를 구별하는 매커니즘을 제고하지 않기 때문에 TRACE요청을 어떻게 처리할지는 중간 매커니즘이 결정을 내리는 구조다.

 

TRACE 요청은 어떠한 엔티티 본문도 보낼 수 없다.

TRACE 응답의 엔티티 본문에는 서버가 받은 요청이 그대로 들어가있다.

 

3.3.7 OPTIONS

웹 서버에게 여러가지 종류의 지원 범위에 대해 물어본다.

예를들어, 서버에게 특정 리소스에 대해 어떤 메서드가 지원되는지 물어볼 수 있다.

(서버가 자신의 리소스에 대해 지원하는 메서드의 목록을 반환해줌.)

 

3.3.8 DELETE

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

하지만 삭제가 수행되는 것을 보장하지는 못한다.

왜냐하면 HTTP는 서버가 클라이언트에게 알리지 않고 요청을 무시하는 것을 허용하기 때문이다.

 

3.3.9 확장 메서드

HTTP는 필요에따라서 확장해도 문제가 없도록 설계되어 있으므로, 새로 기능을 추가해도 과거에 구현된 소프트웨어들의 오동작을 유발하지 않는다.

서버가 구현한 HTTP 서비스의 서버가 관리하는 리소스에 대한 능력을 확장하는 수단을 제공한다.

대부분의 HTTP 어플리케이션에서는 당신이 정의한 커스텀 확장메서드를 사용할 수 없다.

(참고로 확장메서드는 http1.1에 정의되지 않았음)

LOCK, MKCOL, COPY, MOVE 등등 메서드가 있다.

 

 

3.4 상태코드

HTTP 상태 코드는 크게 5가지로 나뉜다.

싱태코드의 존재이유 : 클라이언트에게 그들의 트랜잭션을 이해할 수 있는 쉬운 방법을 제공하기 위해서

 

3.4.1 100-199 : 정보성 상태코드

http1.1에서 도입되었다. 

이거는 복잡함을 감수할만한 가치가 있는지에 대해서 논란이 되고 있다.

 

100 Continue

클라이언트 어플리케이션이 서버에 엔티티 본문을 전송하기 전에 엔티티 본문을 서버가 받아들일 것인지 확인용으로 사용한다.

클라이언트가 서버에게 엔티티를 보내고 싶으면 100 Continue 를 보내고 그 응답을 기다리고,

엔티티를 보내기 싫으면 100 Continue 정보를 보내지 않는다.

이거슨 프로그래머에게 혼란을 주기때문에, 클라이언트는 적당한 timeout을 주고 서버에게 엔티티를 보내는 동작을 수행해야한다.

 

서버는 100 Continue 값이 포함된 헤더를 받으면 100 Continue에 대해 응답을 해야한다.

100 Continue 응답을 보내기전에 엔티티를 받았다면 서버는 상태코드를 안보내도된다.

하지만 서버가 요청을 끝까지 다 읽었으면 그 요청에 대한 최종응답을 보내긴해야한다.

 

프록시는 http1.1보다 이전의 http를 사용하고 있다면 417 Expectation Failed 에러로 응답해야한다.

프록시가 http1.1이전을 따르는 클라이언트를 대신해서 100 Continue를 보내려한다면 100 Continue응답에 대해서는 클라이언트에게 보내면 안된다. (무슨말인지 모른다고 한다.)

 

3.4.2 200-299: 성공 상태코드

클라이언트가 요청을 보내면, 그 요청은 대부분 성공한다.

200: 성공

201: 객체생성됨 (PUT에 대한 응답)

202: 요청이 받아들여짐, 하지만 서버가 어떤 동작도 수행하지는 않음

203: 엔티티 헤더가 검증하지 못한 경우

204: 엔티티 본문이 없는 경우

205: HTML 폼에 채워진 모든 값을 비워라

206: 범위 요청이 성공했다.

 

3.4.3 300-399

클라이언트가 관심있어하는 리소스에 대해 다른 위치를 사용하라고 말해주거나 그 리소스의 내용 대신 다른 대안 응답을 제공한다.

리소스가 옮겨졌다면, 클라이언트가 리소스가 옮겨졌으며 어디서 찾을 수 있는지 알려주기 위해서 redirect 상태코드와 location헤더를 보낸다.

브라우저가 사용자를 귀찮게 하지않고 알아서 새 위치로 이동할 수 있게 해주기 위함이다.

 

300: 리소스들의 목록과 함께 반환

301: 요청한 URL이 옮겨짐

302: 301과 동일

303: 리소스를 다른 URL에서 가져와야함

304: 수정된 일이 없음

305: 리소스가 반드시 프록시를 통해서 접근되어야함

306: deprecated

307: 301과 비슷

 

3.4.4 400-499 클라이언트 에러 상태코드

클라이언트가 서버가 다룰 수 없는 무엇인가를 보낼때 뜨는 에러.

400: 클라이언트가 잘못된 요청을 보냈다!

401: 인증실패

402: (지금안쓰임)

403: 요청이 서버에 의해 거부되다.

404: 요청한 URL을 찾을 수 없다.

405: 지원하지 않는 메서드로 요청을 받았다.

406: URL에 클라이언트가 받아들일 수 없는 것이 있다.

407: 401과 비슷

408: 타임아웃

409: 요청이 서버에서 충돌이 발생할 수 있음

410: 404

411: Content-Length가 없음

412: 조건부 요청중 하나가 실패함

413: 요청의 크기를 서버가 감당못함

414: 요청의 길이가 서버가 감당못함

415: 서버가 이해하지 못하는 요청을 보냄

416: 리소스의 범위가 잘못됨

417: Expect 요청 헤더에 서버가 만족시킬 수 없는 기대가 담겨있는 경우 사용

 

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

클라이언트가 제대로 요청을 보냈는데 서버 자체에서 에러가 발생하는 경우.

500: 서버가 요청을 처리할 수 없게 만드는 에러를 만남

501: 클라이언트가 서버의 능력을 넘은 요청을 함

502: 부모 게이트웨이에 접근하는게 불가능할때

503: 지금 서버가 요청을 처리할 수 없지만, 나중에는 가능할때

504: 타임아웃 (400번대 타임아웃과 다른점은 다른 서버에 보내 요청을 보내는 상태에서 마주하게 된것)

505: 서버가 지원할 수 없는 버전의 프로토콜 사용

 

3.5 헤더

헤더와 메서드는 클라이언트와 서버가 무엇을 하는지 결정하기 위해서 함께 사용된다.

 

3.5.1 일반헤더

클라이언트와 서버 양쪽 모두가 사용한다.

메시지가 어떤 종류이든 상관없이 유용한 정보를 제공한다.

http1.0에서는 일반캐시헤더로 서버로부터 객체를 가져오지않고 캐시를 가져오는 헤더도 있다.

 

3.5.2 요청헤더

서버에게 클라이언트가 받고자하는 정보를 보낸다. 

Accept 헤더 / 조건부 요청 헤더 / 요청 보안 헤더 / 프락시 요청 헤더 등등이 포함된다.

 

3.5.3 응답헤더

클라이언트에게 정보를 제공하기 위한 정보를 보낸다.

협상헤더 / 응답보안헤더

 

3.5.4 엔티티헤더

엔티티 본문에 들어있는 데이터의 타입등등의 정보가 포함된다.

컨텐츠헤더 / 엔티티캐싱헤더 등등

 

확장헤더

http 명세에는 추가되지 않은 커스텀 헤더