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

1. 메시지의 흐름

• HTTP 메시지 : HTTP 애플리케이션 간에 주고받은 데이터의 블록들

 

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

• 인바운드 : 서버방향으로 이동하는 것

• 아웃바운드 : 사용자 에이전트 방향(브라우저) 로 이동하는 것

 

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

• 메시지는 결코 업스트림으로 흐르지 않는다

 

2. 메시지의 각 부분

• 시작줄 : 이것이 어떤 메시지인지 서술

• 헤더 : 속성

• 본문 : 데이터(없을 수도 있음)

 

2.1 메시지 문법

• 요청 메시지의 형식

<메시지> <요청 URL> <버전>
<헤더>

<엔터티 본문>

• 응답 메시지의 형식

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

<엔터티 본문>

• 메서드

• 요청URL

• 버전 : 형식 → HTTP/<메이저>.<마이너>

• 상태 코드 : 요청 중에 무엇이 일어났는지 설명하는 세 자리의 숫자

• 사유 구절 : 숫자로 된 상태 코드의 의미를 사람이 이해할수 있게 설명해주는 짧은 문구

• 헤더들 : 이름, 콜론(:), 선택적인 공백, 값, CRIF가 순서대로 나타나는 0개 이상의 헤더들. 이 헤더의 목록은 빈줄로 끝나 헤더 목록의 끝과 엔터티 본문의 시작을 표시한다.

• 엔터티 본문 : 엔터티 본문이 없더라도 HTTP헤더의 집합은 항상 빈줄(그냥 CRIF)로 끝나야 함에 주의

 

2.2 시작줄

• 요청줄

  • 요청 메시지의 시작줄

  • 서버에서 어떤 동작이 일어나야 하는지 설명해주는 메서드/ 그 동작에 대한 대상을 지칭하는 요청 URL/ 클라이언트가 어떤 HTTP버전으로 말하고 있는지 서버에서 알려주는 HTTP버전을 포함한다.

  • 모든 필드는 공백으로 구분된다.

• 응답줄

  • 응답 메시지의 시작줄

  • 응답 메시지에서 쓰인 HTTP의 버전 / 숫자로 된 상태 코드 / 수행 상태에 대해 설명해주는 텍스트로 된 사유구절이 들어있다.

  • 모든 필드는 공백으로 구분된다.

• 메서드

  • 서버에서 무엇을 해야 하는지 말해준다.

  • HTTP명세를 확장하는 것이므로 확장 메서드라고도 불린다

• 상태 코드

  • 응답의 시작줄에 위치

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

• 사유 구절

• 버전 번호

  • 버전 번호는 HTTP/x.y형식으로 요청과 응답 메시지 양쪽 모두에 기술된다

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

  • HTTP/2.22는 HTTP/2.3보다 크다

 

 

 

2.3 헤더

• HTTP헤더 필드는 시작줄 다음에 오며, 요청과 응답 메시지에 추가 정보를 더한다

• 기본적으로 이름/값 쌍의 목록이다

• 긴 헤더 줄은 여러 줄로 쪼개질 수 있다

2.4 엔터티 본문

2.5 버전 0.9 메시지

• HTTP/0.9는 HTTP프로토콜의 초기 버전이며, 메시지에서 요청은 그저 메서드와 요청 URL을 가지고 있을 뿐이며, 응답은 오직 엔터티로만 되어 있다.

 

3. 메서드

3.1 안전한 메서드(Safe Method)

3.2 GET

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

 

3.3 HEAD

• 응답으로 헤더만을 돌려준다

• 응답의 상태 코드를 통해, 개체가 존재하는지 확인할 수 있다

• 헤더를 확인하여 리소스가 변경되었는지 검사할 수 있다

 

3.4 PUT

• 서버에 문서를 쓴다

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

• 콘텐츠를 변경할 수 있게 해준다

 

3.5 POST

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

• 실제로 HTTP폼을 지원하기 위해 흔히 사용된다

• POST는 서버에 데이터를 보내기 위해 사용한다. PUT은 서버에 있는 리소스에 데이터를 입력하기 위해 사용한다

 

3.6 TRACE

• 클라이언트가 어떤 요청을 할 때, 그 요청은 방화벽, 프락시, 게이트웨이 등의 애플리케이션을 통과할 수 있다. 이들에게는 원래의 HTTP 요청을 수정할 수 있는 기회가 있다. TRACE 메서드는 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려준다

• TRACE요청은 목적지 서버에서 '루프백(loopback)' 진단을 시작한다. 요청 전송의 마지막 단계에 있는 서버는 자신이 받은 요청 메시지를 본문에 넣어 TRACE응답을 되돌려준다. 클라이언트는 자신과 목적지 서버에 있는 모든 HTTP 애플리케이션의 요청/응답 연쇄를 따라가면서 자신이 보낸 메시지가 망가졌거나 수전되었는지, 만약 그렇다면 어떻게 변경되었는지를 확인할 수 있다

• TRACE 메서드는 주로 진단을 위해 사용된다. 예를 들면 요청이 의도한 요청/응답 연쇄를 거쳐가는지 검사할 수 있다.

• TRACE는 메서드를 구별하는 메커니즘을 제공하지 않는다

• TRACE 요청은 어떤 엔터티 본문도 보낼 수 없다. TRACE응답의 엔터티 본문에는 서버가 받은 요청이 그대로 들어있다.

 

3.7 OPTIONS

• 서버에게 특정 리소스에 대해 어떤 메서드가 지원되는지 물어볼 수 있다. (몇몇 서버는 특정 종류의 객체에 대해 특정 동작만을 지원한다)

3.8 DELETE

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

3.9 확장 메서드

 

4. 상태 코드

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

4.2 200-299 : 성공 상태 코드

 

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

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

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

 

5. 헤더

5.1 일반 헤더

• 메시지에 대한 아주 기본적인 정보를 제공하는 헤더

• 일반 캐시 헤더 : HTTP 애플리케이션에게 매번 원 서버로부터 객체를 가져오는 대신 로컬 복사본으로 캐시할 수 있도록 한다

 

5.2 요청 헤더

• 요청 메시지에서만 의미를 갖는 헤더

• 요청이 발생한 곳에서 누가 혹은 무엇이 그 요청을 보냈는지, 클라이언트의 선호나 능력에 대한 정보를 준다

• Accept관련 헤더 : 클라이언트는 Accept관련 해더들을 이용해 서버에게 자신의 선호나 능력을 알려줄 수 있다.클라이언트가 무엇을 원하고 무엇을 할 수 있는지, 원치 않는 것은 무엇인지 알려준다.

• 조건부 요청 헤더 : 클라이언트는 요청에 제약을 넣을 수 있다. 클라이언트는 서버에 요청에 응답하기 전에 먼저 조건이 참인지 확인하게 하는 제약을 포함시킬 수 있다.

• 요청 보안 헤더 : 간단한 인증요구/응답 체계를 통해 트랜잭션을 더 안전하게 만들 수 있다.

• 프락시 요청 헤더

 

5.3 응답 헤더

• 응답 헤더는 클라이언트에게 부가 정보를 제공한다

• 협상 헤더

• 응답 보안 헤더

 

5.4 엔터티 헤더

• 콘텐츠 헤더 : 엔터티의 콘텐츠에 대한 구체적인 정보를 제공한다

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

 

출처 : 데이빗 골리 외 4인, HTTP 완벽 가이드 :웹은 어떻게 동작하는가, 이응준 , 정상일 옮김, 인사이트, 2014