3:56

3장 HTTP 메시지

3.1 메시지의 흐름

HTTP 메시지는 HTTP 애플리케이션 간에 주고 받은 데이터의 블록들이다. 데이터의 블록들은 메시지의 내용과 의미를 설명하는 텍스트 메타 정보로 시작하고 그 다음에 선택적으로 데이터가 올 수 있다.

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

메시지가 클라이언트에서 서버로 향하는 것을 인바운드라 하고, 서버에서 처리가 끝난 뒤 클라이언트에게 돌아오는 것을 아웃바운드라 한다.

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

메시지의 발송자를 수신자의 업스트림이라고 한다. 따라서 모든 메시지는 요청 메시지냐 응답 메시지냐에 관계없이 다운스트림으로 흐른다.

3.2 메시지의 각 부분

시작줄과 헤더는 줄 단위로 분리된 아스키 문자열이다. 각 줄은 캐리지 리턴과 개행 문자로 구성된 두 글자의 줄바꿈 문자열로 끝난다. (CR-커서를 맨 왼쪽으로 이동,LF(라인피드)-커서를 한 칸 아래로 이동) 메시지 본문은 단순히 선택적인 데이터 덩어리이다.

3.2.1 메시지 문법

요청 메시지의 형식은 다음과 같다 :

<메서드><요청URL><버전>

<헤더>

<엔터티 본문>

응답 메시지의 형식은 다음과 같다 :

<버전><상태 코드><사유 구절>

<헤더>

<엔터티 본문> 

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

요청 URL은 요청 대상이 되는 리소스를 지칭한다.

버전은 이 메시지에서 사용 중인 HTTP의 버전이다.

상태 코드는 요청 중에 무엇이 일어났는지 설명하는 세 자리의 숫자로, 첫 번째 자릿수는 성공, 에러와 같은 일반적인 분류를 나타낸다.

사유 구절은 숫자로 된 상태 코드의 의미를 사람이 이해할 수 있게 설명해주는 짧은 문구이다. 오로지 사람에게 읽히는 목적으로만 존재한다.

헤더는 이름, 콜론(:), 선택적인 공백, 값, CRLF가 순서대로 나타나며 0개 이상으로 이루어진다.

엔터티 본문은 임의의 데이터 블록으로, 모든 메시지가 엔터티 본문을 갖는 것은 아니다.

3.2.2 시작줄

모든 HTTP메시지는 시작줄로 시작한다. 요청 메시지의 시작줄은 무엇을 해야 하는지 말해주며 응답 메시지의 시작줄은 무슨 일이 일어났는지 말해준다.

① 요청줄

요청 메시지는 서버에게 리소스에 대해 무언가를 해달라고 부탁한다. 메서드와 요청URL, 버전으로 구성되며 이들은 공백으로 구분된다.

② 응답줄

응답 메시지는 수행 결과에 대한 상태 정보와 함께 결과 데이터를 클라이언트에게 돌려준다. 버전, 상태 코드, 사유 구절로 이루어지며 이들은 공백으로 구분된다.

③ 메서드

GET, HEAD, POST, PUT, TRACE, OPTIONS, DELETE 등이 있다. 모든 서버가 이러한 메서드를 다 구현할 수 있는 것은 아니며 어떤 서버는 그들만의 메서드를 추가로 구현했을 수도 있다. 이를 확장 메서드라 한다.

④ 상태 코드

상태 코드는 세 자리의 숫자로 클라이언트에게 무엇이 일어났는지 말해준다. 200~299까지는 성공을 나타내며, 300에서 399까지는 리소스가 옮겨졌음을 뜻한다. 400~499까지는 클라이언트가 잘못된 요청을 한 것이며 500~599까지는 서버에서 무언가 실패했음을 나타낸다.

⑤ 사유 구절

사유 구절은 상태 코드와 일대일로 대응되며, 상태 코드의 사람이 이해하기 쉬운 버전이다.

⑥ 버전 번호

버전 번호는 HTTP로 대화하는 애플리케이션들에게 대화 상대의 능력과 메시지의 형식에 대한 단서를 제공해주기 위한 것이다. (메시지가 특정 버전이라는 것이 아니다.)

3.2.3 헤더

헤더 필드는 요청과 응답 메시지에 추가 정보를 더하며 기본적으로 이름/값 쌍의 목록이다. 헤더는 일반 헤더, 요청 헤더, 응답 헤더, Entity 헤더, 확장 헤더로 분류된다. 대부분 이름, 콜론, 공백, 필드 값, CRLF가 순서대로 온다.

3.2.4 엔터티 본문

엔터티 본문은 이미지, 비디오, HTML 문서 등을 수송한다.

3.2.5 버전 0.9 메시지

3.3 메서드

3.3.1 안전한 메서드

안전한 메서드란 HTTP 요청의 결과로 서버에 어떤 작용도 없음을 의미한다. (GET, HEAD 메서드가 대표적이나 웹 개발자가 어떻게 하느냐에 따라 작용을 발생시킬수도 있다.) 안전한 메서드의 목적은, 서버에 어떠한 영향을 줄 수 있는 안전하지 않은 메서드가 사용될 때 사용자들에게 그 사실을 알려주는 HTTP 애플리케이션을 만들 수 있도록 하는데 있다.

3.2.2 GET

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

3.3.3 HEAD

메서드는 정확히 GET처럼 행동하지만 서버는 응답으로 헤더만을 돌려준다. 즉 HEAD를 사용하면 리소스를 가져오지 않고도 리소스의 기본적 정보를 알아낼 수 있다. (내용은 알 수 없다.) 응답의 상태 코드를 통해 개체가 존재하는지 알 수 있으며, 헤더를 확인하여 리소스가 변경되었는지 검사할 수 있다.

3.3.4 PUT

PUT 메서드는 서버에 문서를 쓴다. 즉 서버가 요청 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 이미 URL이 존재한다면 본문을 사용하여 교체한다. 콘텐츠를 변경할 수 있게 하는 PUT의 특성상 수행 전 사용자에게 로그인을 요구할 확률이 높다.

3.3.5 POST

POST는 서버에 입력 데이터를 전송한다. POST와 PUT의 차이점은 POST는 서버에 데이터를 보내기 위해 사용되나 PUT은 서버에 있는 리소스에 데이터를 입력하기 위해 사용한다는 것이다.

3.3.6 TRACE

TRACE 메서드는 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려준다. 요청 전송의 마지막 단계에 있는 서버는 자신이 받은 요청 메시지를 본문에 넣어 TRACE 응답을 되돌려준다. 클라이언트는 자신과 목적지 서버 사이에 있는 모든 HTTP 애플리케이션(프락시 등)의 요청/응답 연쇄를 따라가면서 자신이 보낸 메시지가 어떻게 수정되었는지 확인할 수 있다.

3.3.7 OPTIONS

OPTIONS 메소드는 웹 서버에게 특정 리소스에 대해 어떤 메서드가 지원되는지 등 여러 지원 범위에 대해 물어본다. 클라이언트는 실제로 리소스에 접근하지 않고도 어떻게 접근하는 것이 최선인지 알 수 있다,

3.3.8 DELETE

DELETE 메서드는 서버에게 요청 URL로 저장한 리소스를 삭제할 것을 요청한다. 다만 HTTP 명세는 서버가 클라이언트에게 알리지 않고 요청을 무시하는 것을 허용하므로 리소스 삭제를 보장할 수 없다.

3.3.9 확장 메서드

HTTP는 필요에 ᄄᆞ라 확장해도 문제가 없도록 설게되어 개발자들은 그들의 서버가 구현한 HTTP 서비스의 서버가 관리하는 리소스에 대한 능력을 확장할 수 있다.

3.4 상태 코드

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

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

상태코드 100 Continue는 요청의 시작 뿐 일부가 받아들여졌으며, 클라이언트는 나머지를 계속 보내야 함을 의미한다.

- 클라이언트와 100 Continue

만약 클라이언트가 엔터티를 서버에 보내려고 하고, 그 전에 100 Continue 응답을 기다리겠다면, 클라이언트는 값을 100-Continue로 하는 Expect 요청 헤더를 보낼 필요가 있다. 만약 엔터티를 보내지 않으려면 100-Continue Expect 헤더를 보내지 않아야 한다. 만약 이를 보낸다면 클라이언트가 엔터티를 보낼거라고 생각하게 만들어 서버를 혼란에 빠뜨릴 뿐이기 때문이다. 또, 100-Continue Expect 헤더를 보낸 클라이언트는 서버가 100 Continue 응답을 보내주기를 막연히 기다리기만 해서는 안된다. 약간의 타임아웃 후 그냥 엔터티를 보내야 한다.

-서버와 100 Continue

서버가 100-Continue Expect헤더가 포함된 요청을 받으면, 100Continue 응답 혹은 에러 코드로 답해야 한다. 또, 100-Continue 응답을 받을 것을 의도하지 않은 클라이언트에게 100 Continue 상태 코드를 보내서는 안 된다. 또 서버가 100 Continue 응답을 보내기 전 엔터티의 일부 혹은 전체를 수신하였다면, 서버는 이 상태 코드를 보낼 필요가 없다. 클라이언트는 이미 계속 전송하기로 결정하였기 때문이다. 그러나 요청을 끝까지 다 읽은 후에는 그 요청에 대한 최종 응답을 보내야 한다.

3.4.2 200-299 : 성공 상태 코드

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

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

리다이렉션 상태 코드는 클라이언트가 관심있어 하는 리소스에 대해 다른 위치를 사용하라고 말해주거나 다른 대안 응답을 제공한다. 리다이렉션 코드 중 몇몇은 리소스에 대한 애플리케이션의 로컬 복사본이 원래 서버와 비교했을 때 유요한지 확인하기도 한다.

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

클라이언트가 서버가 다룰 수 없는 무언가를 보낼 경우 이러한 에러가 발생한다. 대표적인 것이 존재하지 않는 URL에 대한 요청이다.

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

클라이언트가 올바른 요청을 보냈음에도 서버 자체에서 에러가 발생할 때 나타나는 코드이다. 프락시는 클라이언트 입장에서 서버와 대화를 시도할 때 자주 에러를 만나게 되는데, 이때 프락시가 5XX 서버 에러 상태 코드를 생성한다.

3.5 헤더

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

① 일반 헤더

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

②요청 헤더

요청 메시지를 위한 헤더로, 서버에게 클라이언트가 받고자 하는 데이터 타입과 같은 부가 정보를 제공한다.

③응답 헤더

클라이언트가 어떤 종류의 서버와 대화하고 있는가와 같은 클라이언트에게 정보를 제공하기 위한 헤더이다.

④엔터티 헤더

엔터티 본문에 대한 헤더로, 엔터티 본문의 데이터 타입과 같은 정보를 제공한다.

⑤확장 헤더

애플리케이션 개발자들에 의해 만들어졌지만 아직 승인된 HTTP 명세에는 추가되지 않은 비표준 헤더이다.