3.1 메시지의 흐름
인바운드, 아웃바운드, 업스트림, 다운스트림은 메시지의 방향을 의미하는 용어
3.1.1 메시지는 원 서버 방향을 인바운드로 하여 송신된다
http는 인바운드와 아웃바운드라는 용어를 트랜잭션의 방향을 표현하기 위해 사용한다. 메시지가 원 서버로 향하는 것은 인바운드로 이동하는 것이고, 모든 처리가 끝난 뒤 메시지가 사용자 에이전트로 돌아오는 것은 아웃바운드로 이동하는 것이다.
3.1.2 다운스트림으로 흐르는 메시지
http 메시지는 강물과 같이 흐른다. 요청이든 응답메시지든 관계 없이 모든 메시지는 다운스트림으로 흐른다. 메시지 발송자는 수신자의 업스트림.
3.2 메시지의 각 부분
HTTP 메시지는 시작줄 + 헤더 + 본문.
시작줄과 헤더는 그냥 줄 단위로된 아스키 문자열이다. 각 줄은 캐리지 리턴(ASCII 13)과 개행 문자(ASCII 10)로 구성된 두 글자의 줄바꿈 문자열로 끝난다. 이 줄바꿈 문자열을 ‘CRLF’라 쓴다.
본문은 단순히 선택적인 영역. 텍스트나 이진 데이터를 포함할 수도 비었을 수도 있다.
3.2.1 메시지 문법
요청 메시지 형식
<method> <requst URL> <version>
<header>
<body>
응답 메시지 형식
<verison> <status code> <reason phrase>
<header>
<body>
헤더들
이름, :, 선택적인 공백, 값, CRLF 가 순서대로 나타나는 0개 이상의 헤더들. 이 헤더의 목록은 빈 줄(CRLF)로 끝나 헤더 목록의 끝과 엔티티 본문의 시작을 표시한다.
버전 번호
버전 번호는 HTTP/x.y 형식으로 요청과 응답 메시지 양쪽 모두에 기술된다. 이건 http 애플리케이션들이 자신이 따르는 프로토콜의 버전을 상대방에게 말해주기 위한 수단이 딘다.
버전 번호는 어떤 앱이 지원하는 가장 높은 http 버전을 가리킨다. 때때로 혼란이 있는데 http/1.0 앱이 1.1로된 응답 받았을때 이를 1.1 으로 해석하는 경우가 있기 때문이다. 응답의 버전이 1.1 이라는 것은 사실 응답을 보낸 애플리케이션이 1.1 까지 이해할 수 있음을 의미한다.
버전 번호는 또한 분수로 다루어 지지 않는다. 2.22 가 2.3 보다 크다. 22가 3보다 큰 숫자이기 때문이다.
3.2.5 버전 0.9 메시지
0.9는 http 초기 버전.
이것도 요청과 응답으로 이루어져 있지만, 요청은 그저 메서드와 요청 URL을 갖고 있을 뿐이며, 응답은 오직 엔티티로만 되어있다.
3.3 메서드
3.3.1 안전한 메서드
GET, HEAD 같은건 안전하다 할 수 있는데, 이는 이것들을 사용하는 http 요청의 결과로 서버에 어떤 작용도 없어서다.
3.3.7 OPTIONS
options는 웹 서버에 여러 가지 종류의 지원 범위에 대해 물어본다. 서버에서 특정 리소스에 대해 어떤 메서드가 지원되는지 물어볼 수 있다. 몇몇 서버는 특정 종류의 객체에 대해 특정 동작만 지원한다.
3.3.9 확장 메서드
http는 필요에 따라 확장해도 무바하도록 설계되어 있다. 새로 기능 추가해도 과거에 구현된 소프트웨어들의 오동작을 유발안한다. 확장 메서드는 1.1에 정의 안된 메서드.
개발자가 직접 정의한것임.
만약 웹서버가 자기는 모르는 메서드를 요청한다면 501 Not Implemented 상태로 응답하면 된다. 확장 메서드 다룰때는 엄격하게 보내고 관대하게 받아들여라 라는 오랜 규칙 따르는게 좋다.
3.4 상태 코드
3.4.1 100 - 199: 정보성 상태 코드
1.1 때 도입.
100 Continue 에 대해 다루는데 자세히 알고싶으면 96(68) 참고해보기.
3.4.2 200 - 299: 성공 상태 코드
3.4.3 300 - 399: 리다이렉션 상태 코드
리다이렉션 상태 코드 중 몇몇은 리소스에 대한 애플리케이션의 로컬 복사본이 서버에 비교했을 때 유효한지 확인하기 위해 사용된다. 예를 들어, http 애플리케이션은 그의 리소스에 대한 로컬 복사본이 여전히 최신인지 혹은 원래 서버에 있는 리소스가 수정되었는지 검사할 수 있다.
클라는 97년 10월 이후에 수정된 경우에만 문서 가져오라고 말하기 위해 특별한 If-Modified-Since 헤더를 전송한다. 그 문서가 그 날짜 이후 변한게 없다면, 서버는 콘텐츠 대신 304 상태 코드로 답할 것.
- 301 Moved Permanently
- 요청한 URL이 옮겨졌을 때 사용한다. 응답은 Location 헤더에 현재 리소스가 존재하고 있는 URL을 포함해야한다.
- 302 Found
- 301과 같다. 그러나 클라는 Location 헤더로 주어진 URL을 리소스를 임시로 가리키기 위한 목적으로 사용해야한다. 이후의 요청에는 원래 URL을 사용해야한다.