ch3

3.1 메시지의 흐름

HTTP 메시지는 HTTP 애플리케이션 간에 주고받은 데이터의 블록
데이터의 블록들은 메시지의 내용과 의미를 설명하는 텍스트 메타 정보로 시작하고 그 다음에 선택적으로 데이터가 올 수 있음
'인바운드', '아웃바운드' , '업스트림', '다운스트림'은 메시지의 방향을 의미하는 용어

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

HTTP는 인바운드와 아웃바운드라는 용어를 트랜책션 방향을 표현하기 위해 사용
메시지가 원 서버로 향하는 것은 인바운드
모든 처리가 끝난 뒤에 메시지가 사용자 에이전트로 돌아오는 것은 아웃바운드

3. 1 .2 다운스트림으로 흐르는 메시지

요청 메시지냐 응답 메시지냐에 관계없이 모든 메시지는 다운스트림으로 흐름

3.2 메시지의 각 부분

메시지는 시작줄, 헤더 블록, 본문 이렇게 세 부분으로 이루어짐
시작줄과 헤더는 그냥 줄 단위로 분리된 아스키 문자열
각 줄은 캐리지 리턴 (ASCII 13)과 개행 문자 (ASCII 10)로 구성된 두 글자의 줄바꿈 문자열으로 끝남
줄바꿈 문자열은 'CRLF'라고 씀
엔터티 본문이나 메시지 본문(혹은 그냥 '본문')은 단순히 선택적인 데이터 덩어리
시작줄이나 헤더와는 달리, 본문은 텍스트나 이진 데이터를 포함할 수도 있고 그냥 비 어 있을 수도 있음

3.2.1 메시지 문법

모든 HTTP 메시지는 요청 메시지나 응답 메시지로 분류
요청 메시지의 형식

<메서드> <요청 URL> <버전>
<헤더>
<엔터티 본문>

응답 메시지의 형식

<버전> <상태 코드> <사유 구절>
<헤더>
<엔터티 본문>

메서드

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

요청 URL

요청 대상이 되는 리소스를 지칭하는 완전한 URL 혹은 URL의 경로 구성요소

버전

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

HTTP/<메이저>.<마이너>

상태코드

요청 중에 무엇이 일어났는지 설명하는 세 자리의 숫자

사유 구절

숫자로 된 상태 코드의 의미를사람이 이해할 수 있게 설명해주는 짧은 문구
상태 코드 이후부터 줄바꿈 문자열까지가 사유 구절
사유 구절은 오로지 사람에게 읽히기 위한 목적으로만 존재하는 것

헤더들

이름, 콜론(:), 선택적인 공백, 값, CRLF가 순서 대로 나타나는 0개 이상의 헤더들

엔터티 본문

엔터티 본문은 임의의 데이터 블록을 포함
헤더나 엔터티 본문이 없더라도 HTTP 헤더의 집합은 항상 빈 줄(그냥 CRLF)로 끝나야 함에 주의

3.2.2 시작줄

요청줄

요청 메시지의 시작줄, 혹은 요청줄에는 서버에서 어떤 동작이 일어나야 하는지 설명해주는 메서드와 그 동작에 대한 대상을 지칭하는 요청 URL이 들어 있음
모든 필드는 공백으로 구분

응답줄

응답 메시지는 수행 결과에 대한 상태 정보와 결과 데이터를 클라이언트에게 돌려줌
응답 메시지의 시작줄 혹은 응답줄에는 응답 메시지에서 쓰인 HTTP의 버전, 숫자로 된 상태 코드, 수행 상태에 대해 설명해주는 텍스트로 된 사유 구절이 들어있음

메서드

요청의 시작줄은 메서드로 시작하며, 서버에게 무엇을 해야 하는지 말해줌

메서드

설명

메시지 본문이 있는가?

GET

서버에서 어떤 문서를 가져온다.

없음

HEAD

서버에서 어떤 문서에 대해 헤더만 가져온다.

없음

POST

서버가 처리해야 할 데이터를 보낸다.

있음

PUT

서버에 요청 메시지를 본문을 저장한다.

있음

TRACE

메시지가 프락시를 거쳐 서버에 도달하는 과정을 추적한다.

없음

OPTIONS

서버가 어떤 메서드를 수행할 수 있는지 확인한다.

없음

DELETE

서버에서 문서를 제거한다.

없음

상태 코드

메서드가 서버에게 무엇을 해야 하는지 말해주는 것처럼, 상태 코드는 클라이언트에게 무엇이 일어났는지 말해줌
200에서 299까지의 상태 코드는 성공을 나타낸다. 500에서 399까지의 코드는 리소스 옮가겨졌음을 뜻
400에서 499까지의 코드는 클라이언트가 뭔가 잘못된 요청을음을 의미
500에서 599까지의 코드는 서버에서 뭔가 실패했음을 의미

전체 범위

정의된 범위

분류

100-199

100-101

정보

200-299

200-206

성공

300-399

300-305

리다이렉션

400-499

400-415

클라이언트 에러

500-599

500-105

서버 에러

사유 구절

상태 코드에 대한 글로 된 설명을 제공
사유 구절은 상태 코드와 일대일로 대응
HTTP 명세는 사유 구절이 어때야 한다는 어떤 엄격한 규칙도 제공하지 않음

버전 번호

버전 번호는 HTTP/x.y 형식으로 요청과 응답 메시지 양쪽 모두에
HTTP 애플리케이션들이 자신이 따르는 프로토콜의 버전을 상대방에게 말해주기 위한 수단

3.2.3 헤더

HTTP 헤더 필드는 요청과 응답 메시지에 추가 정보를 더함
이름/값 쌍의 목록

헤더 분류

일반 헤더 : 요청과 응답 양쪽에 모두 나타날 수 있음
요청 헤더 : 요청 에 대한 부가 정보를 제공
응답 헤더 : 웅답에 대한 부가 정보를 제공
Entity 헤더 : 본문 크기와 콘텐츠, 혹은 리소스 그 자체를 서술
확장 헤더 : 명세에 정의되지 않은 새로운 헤더

헤더를 여러 줄로 나누기

긴 헤더 줄은 그들을 여러 줄로 쪼개서 더 읽기 좋게 만들 수 있는데, 추가 줄 앞에는 최소 하나의 스페이스 혹은 탭 문자가 와야 함

3.2.4 엔터티 본문

HTTP 메시지는 이미지, 비디오, HTML 문서, 소프트웨어 애플리케이션, 신용카드 트랜잭션, 전자우편 등 여러 종류의 디지털 데이터를 실어 나를 수 있음

3.2.5 버전 0.9 메시지

HTTP/0.9 메시지도 마찬가지로 요청과 응답으로 이루어져 있지만, 요청은 그저 메서드와 요청 URL를 갖고 있을 뿐
응답은 오직 엔터티로만 되어 있음

3.3 메서드

메서드는 대부분 제한적으로 사용될 것

3.3.1 안전한 메서드 (Safe Method)

HTTP는 안전한 메서드라 불리는 메서드의 집합을 정의
GET과 HEAD 메서드는 안전하다고 할 수 있는데, 이는 GET이나 HEAD 메서드를 사용하는 HTTP 요청의 결과로 서버에 어떤 작용도 없음을 의미
안전한 메서드가 서버 에 작용을 유발하지 않는다는 보장은 없음
안전한 메서드의 목적은, 서버에 어떤 영향을 줄 수 있는 안전하지 않은 메서드가 사용될 때 사용자들에게 그 사실을 알려주는 HTTP 애플리케이션을 만들 수 있도록 하는 것

3.3.2 GET

주로 서버에게 리소스를 달라고 요청하기 위해 쓰임
HTTP/1.1은 서버가 이 메서드를 구현할 것을 요구함

3.3.3 HEAD

HEAD 메서드는 정확히 GET처럼 행동하지만, 서버는 응답으로 헤더만을 돌려줌
리소스를 가져오지 않고도 그에 대해 무엇인가(타입이라거나)를 알아낼 수 있다.
응답의 상태 코드를 통해, 개체가 존재하는지 확인할 수 있다.
헤더를 확인하여 리소스가 변경되었는지 검사할 수 있다.
HTTP/1.1 준수를 위해서는 HEAD 메서드가 반드시 구현되어어야 함

3.3.4 PUT

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

3.3.5 POST

POST 메서드는 서버에 입력 데이터를 전송하기 위해 설계

3.3.6 TRACE

클라이언트가 어떤 요청을 할 때, 그 요청은 방화벽, 프락시, 게이트웨이 등의 애플리케이션을 통과할 수 있음
HTTP 요청을 수정할 수 있는 기회 있음
TRACE 메서드는 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려줌
TRACE 요청은 목적지 서버에서 '루프백(loopback)' 진단을 시작
요청 전송의 마지막 단계에 있는 서버는 자신이 받은 요청 메시지를 본문에 넣어 TRACE 응답을 되돌려줌
클라이언트는 자신과 목적지 서버 사이에 있는 모든 HTIP 애플리케이션의 요청/응답 연쇄를 따라가면서 자신이 보낸 메시지가 망가졌거나 수정되었는지, 만약 그렇다면 어 떻게 변경 되었는지 확인할 수 있음
TRACE는 진단을 위해 사용할 때는 괜찮지만, 그 대신 중간 애플리케이션이 여러 다른 종류의 요청(GET, HEAD, POST 등 각각 다른 메서드를 사용한)들을 일관되게 다룬다고 가정하는 문제가 있다.(?)
TRACE 요청은 어떠한 엔터티 본문도 보낼 수 없음
TRACE 응답의 엔터티 본문에는 서버가 받은 요청이 그대로 들어 있음
R : 루프백(loopback)

3.3.7 OPTIONS

OPTIONS 메서드는 웹 서버에게 여러 가지 종류의 지원 범위에 대해 물어봄
이 메서드는 여러 리소스에 대해 실제로 접근하지 않고도 그것들을 어떻게 접근하는 것이 최선인지 확인할 수 있는 수단을 클라이언트 애플리케이션에게 제공

3.3.8 DELETE

서버에게 요청 URL로 지정한 리소스를 삭제할 것을 요청
클라이언트는 삭제가 수행되는 것을 보장하지 못함
HTTP 명세는 서버가 클라이언트에게 알리지 않고 요청을 무시하는 것을 허용하기 때문

3.3.9 확장 메서드

HTTP는 필요에 따라 확장해도 문제가 없도록 설계
새로 기능을 추가해도 과거에 구현된 소프트웨어들의 오동작을 유발하지 않음
확장 메서드는 HTTP/1.1 명세에 정의되지 않은 메서드
그들은 개발자들에게 그들의 서버가 구현한 HTTP 서비스의 서버가 관리하는 리소스에 대한 능력을 확장하는 수단을 제공한다.
모든 확장 메서드가 형식을 갖춘 명세로 정의된 것은 아니라는 점에 주의
만약 당신이 어떤 확장 메서드를 정의한다면, 그것은 대부분의 HTTP 애플리케이션이 이해할 수 없을 것
Q : HTTP 애플리케이션이 이해할 수 없을 것 -> 이용할 수 없는 것 라는 표현이 더 적절하지 않은가?
Q : 405, 501의 차이는? 어떤 경우에 올바른 선택인가?
R :

3.4 상태 코드

HTTP 상태 코드는 크게 다섯 가지로 나뉨

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

클라이언트와 100 Continue

100 Continue는 HTTP 클라이언트 애플리케이션이 서버에 엔터티 본문을 전송하기 전에 그 엔터티 본문을 서버가 받아들일 것인지 확인하려고 할 때, 그 확인 작업을 최적화하기 위한 의도로 도입된 것
100-Continue를 서버가 다루거나 사용할 수 없는 큰 엔터티를 서버 에게 보내지 않으려는 목적으로만 사용
Q : '다루거나 사용할 수 없는 큰 엔터티를' 이 문맥에서 다룬다와 사용의 차이는 무엇인가?

서버와 100 Continue

서버가 100-Continue 값이 담긴 Expect 헤더가 포함된 요청을 받는다면, 100 Continue 응답 혹은 에러 코드로 답해야 함
서버가 100 Continue 응답을 보낼 기회를 갖기 전에 어떤 이유로 인해 엔터티의 일부(혹은 전체)를 수신하였다면, 서버는 이 상태 코드를 보낼 필요가 없음
만약 서버가 100 continue 응답을 받을 것을 의도한 요청을 받고 난 상태에서 엔터티 본문을 읽기 전에 요청을 끝내기로 결정했다면(에러 등의 이유로), 서버는 그냥 응답을 보내고 연결을 닫아서는 안 됨
Q : '100 Continue 응답 혹은 에러 코드로 답' 에러 코드는 417을 전달하는가? 아니면 다른 코드인가?

프락시와 100 Continue

클라이언트로부터 100-continue 응답을 의도한 요청을 받은 프락시는 몇 가지 해야 할 일이 있음
다음 흡(next-hop) 서버(6장에서 다룬다)가 HTTP/1.1을 따르거나 혹은 어 떤 버 전을 따르는지 모른다면, Expect 헤더를 포함시 켜서 요청을 다음으로 전달해야 함
만약 다음 흡의 서버가 1.1보다 이전 버전의 HTTP를 따른다는 것을 알고 있다면, 프락시는 417 Expectation Failed 에러로 응답
프락시가 HTTP/1.0이나 이전 버전을 따르는 클라이언트를 대신하여 Expect 헤더와 100-continue 값을 요청 에 포함시키 기로 결정했다면, 프락시는 100 Continue 응답을 클라이언트에 전달해서는 안 됨

3.4.2 200-299: 성공 상태 코드

서버는 대응하는 성공을 의미하는 상태 코드의 배열을 갖고 있으며, 각각 다른 종류의 요청에 대응

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

리다이렉션 상태 코드는 클라이언트가 관심있어 하는 리소스에 대해 다른 위치를 사용하라고 말해주거나 그 리소스의 내용 대신 다른 대안 응답을 제공
리다이렉션 상태 코드 중 몇몇은 리소스에 대한 애플리케이션의 로컬 복사본이 원래 서버와 비교했을 때 유효한지 확인하기 위해 사용
302, 303, 307 상태 코드 사이에서 중복되는 부분
- 상태 코드들이 어떻게 사용되는가에 대해서는 약간 미묘한 차이가 있는데, 이는 주로 HTTP/1.0과 HTTP/1.1 애플리케이션이 이 상태 코드를 다루는 방식의 차이점에 기인

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

클라이언트는 서버가 다를 수 없는 무엇인가를 보낸다. 잘못 구성된 요청 메시지 같은 것이 있을 수 있으며 , 가장 흔한 것은 존재하지 않는 URL에 대한 요청

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

클라이언트가 올바른 요청을 보냈음에도 서버 자체에서 에러가 발생하는 경우

3.5 헤더

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

일반 헤더 (General Headers)

일반 헤더는 클라이언트와 서버 양쪽 모두가 사용
클라이언트, 서버, 그리고 어딘가에 메시지를 보내는 다른 애플리케이션들을 위해 다양한 목적으로 사용

요청 헤더 (Request Headers)

요청 헤더는 요청 메시지를 위한 헤더
클라이언트가 받고자 하는 데이터의 타입이 무엇인지와 같은 부가 정보를 제공

응답 헤더(Response Headers)

응답 메시지는 클라이언트에게 정보를 제공하기 위한 자신만의 헤더

엔터티 헤더(Entity Headers)

엔터티 헤더란 엔터티 본문에 대한 헤더

Content-Type: text/html; charset=iso-latin-1

확장 헤더(Extension Headers)

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

3.5.1 일반 헤더

메시지에 대한 아주 기본적인 정보를 제공
메시지가 어떤 종류이든 상관없이 유용한 정보를 제공

일반 캐시 헤더

HTTP/1.0은 HTTP 애플리케이션에게 매번 원 서버로부터 객체를 가져오는 대신 로컬 복사본으로 캐시할 수 있도록 해주는 최초의 헤더를 도입

3.5.2 요청 헤더

요청 헤더는 요청 메시지에서만 의미를 갖는 헤더
요청이 최초 발생한 곳에서 누가 혹은 무엇이 그 요청을 보냈는지에 대한 정보
클라이언트의 선호나 능력에 대한 정보

Accept 관련 헤더

클라이언트는 Accept 관련 헤더들은 이용해 서버에게 자신의 선호와 능력을 알려줄 수 있음
Accept 관련 헤더들은 서버와 클라이언트 양쪽 모두에게 유익

조건부 요청 헤더

조건부 요청 헤더를 사용하면, 클라이언트는 서버에게 요청에 응답하기 전에 먼저 조건이 참인지 확인하게 하는 제약을 포함시킬 수 있음

요청 보안 헤더

HTTP는 자체적으로 요청을 위한 간단한 인증요구/응답 체계를 갖고 있음

프락시 요청 헤더

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

3.5.3 응답 헤더

응답 헤더는 클라이언트에게 부가 정보를 제공
누가 응답을 보내고 있는지 혹은 응답자의 능력은 어떻게 되는지 알려주며, 더 나아가 응답에 대한 특별한 설명도 제공

협상 헤더

HTTP/1.1은 서버와 클라이언트가 어떤 표현을 택할 것인가에 대한 협상을 할 수 있도록 지원

응답 보안 헤더

3.5.4 엔터티 헤더

HITP 메시지의 엔터티에 대해 설명하는 헤더들은 많음
일반적으로 엔터티 헤더는 메시지의 수신자에게 자신이 다루고 있는 것이 무엇인지 말해줌

콘텐츠 헤더

콘텐츠 헤더는 엔터티의 콘텐츠에 대한 구체적인 정보를 제공
콘텐츠의 종류, 크기, 기타 콘텐츠를 처리할 때 유용

엔터티 캐싱 헤더

일반 캐싱 헤더는 언제 어떻게 캐시가 되어야 하는지에 대한 지시지를 제공
엔터티 캐싱 헤더는 엔터티 캐싱에 대한 정보를 제공

Previousch4 Nexthttp떠도는 글 정리

Last updated 6 years ago

Was this helpful?