3. HTTP 메시지

메시지의 흐름

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

메시지는 클라이언트, 서버, 프록시 사이를 흐르며 인바운드, 아웃바운드, 업스트림, 다운스트림은 메시지의 방향을 의미하는 용어다.

 

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

메시지가 원 서버로 향하는 것(클라이언트 -> 서버)은 인바운드, 모든 처리가 끝난 뒤 메시지가 사용자 에이전트로 돌아오는 것(서버 -> 클라이언트)을 아운바운드라고 한다.

 

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

모든 메시지는 다운스트림으로 흐른다.

요청에서는 프록서1이 프록시3의 업스트림이지만 응답에서는 프록시3의 다운스트림이다.

 

메시지의 각 부분

HTTP는 시작줄, 헤더블록, 본문 이렇게 3개의 부분으로 이루어진다.

각 줄은 CRLF으로 구분된다.

 

메시지 문법

응답 HTTP

요청 HTTP

<메소드><url><버전>
<헤더>
<엔터티 본문>

 

응답 HTTP

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

 

메소드

 

상태코드

 

사유구절

사유구절은 상태코드와 1:1로 매핑된다. 상태코드를 사람이 이해하기 쉽게 풀어 썼다고 보면 된다.

 

버전번호

어떤 애플리케이션이 지원하는 가장 높은 HTTP 버전을 가리킨다. (HTTP의 포맷 버전이 아니다)

버전번호는 가끔 혼란을 야기하는데 -> HTTP/1.0 애플리케이션이 버전번호가 HTTP/1.1로 응답을 받았을 때 이를 HTTP/1.1메시지라고 해석하는 경우가 있기 때문이다. 하지만 이는 응답을 보낸 애플리케이션이 HTTP/1.1까지 이해할 수 있음을 의미하는 것이다.

또한 HTTP/1.1에서 1.1은 1과 1/10이 아니라 그냥 1과 1이다

HTTP/1.10이 HTTP/1.2보다 버전이 높다. 왜냐면 10>2니까.

 

헤더를 여러 줄로 나누기

긴 헤더 줄은 여러 줄로 쪼개서 나눌 수 있는데 추가 된 줄 앞에는 최소 하나의 스페이스나 탭이 와야한다.

 

 

메소드

안전한 메소드

GET과 HEAD는 안전한 메소드다 -> 사용하는 HTTP요청의 결과로 서버에서 어떤 작용도 없기때문.

작용이 없다는 것은 HTTP결과로 인해 서버에서 일어나는 일은 아무것도 없다는 뜻이다.

하지만 서버에 작용을 유발하지 않는다는 뜻은 아니다.

 

HEAD

응답으로 헤더만을 돌려준다 -> 클라이언트가 리소스를 실제로 가져올 필요 없이 헤더만을 조사할 수 있도록 해준다.

• 리소스를 가져오지 않고도 그에 대해 무언가 알아낼 수 있다. (엔터티 타입, 리다이렉트 여부나 쿠키같은 것들일까....)
• 응답 상태 코드를 통해 개체가 존재하는지 확인할 수 있다.
• 리소스가 변경되었는지 검사할 수 있다 (content-length등을 사용할 듯

PUT

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

 

POST

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

 

TRACE

클라이언트의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려준다.

서버는 자신이 받은 요청 메시지를 본문에 넣어 TRACE응답으로 돌려준디 (그럼 실제 응답은...?) 클라이언트는 이걸 보면서 자신의 요청이 빠졌나 망가졌나 확인할 수 있다. (그럼 post에 대한 요청값을 알고 싶을때는 메소드를 어떻게 보내지...?)

 

OPTIONS

해당 url에 지원하는 메소드 종류를 알려준다.

 

DELETE

삭제를 요청할 때 날린다.

 

확장 메소드

HTTP/1.1 명세에 정의되지 않은 헤더들. 사용자가 직접 정의해서 날릴 수 있다.

LOCK, MKCOL, COPY, MOVE 머 이런 애들이 있다.

"엄격하게 보내고 관대하게 받아들여라"

"be conservative in what you send, be liveral in what you accept" Postel의 법칙

 

 

상태코드

100-199: 정보성 상태코드

1.1에서 도입되었다. 복잡함을 감수할 만한 가치가 있는지 논란 중

 

100 Continue

요청의 시작 일부가 받아들여졌음. 클라이언트는 나머지를 계속 이어서 보내야 함을 의미. 

클라리언트 애플리케이션이 서버에 인터티 본문을 전송하기 전에 그 엔터티 본문을 서버가 받아들일 것인지 확인하려고 할 때, 그 확인 작업을 최적화하기 위한 의도로 도입된 것 (...? 읽고도 모르겠음, 서버가 준비 됐는지 확인하려고 보내나? health체크...?)

 

클라이언트와 100 Continue

Expect: 100-continue

 

만약 클라이언트가 엔터티를 서버에게 보내려고 하고, 그 전에 100 응답을 기다리겠다면 클라이언트는 값을 100-continue로 하는 Expect 요청 헤더를 보낼 필요가 있다. 만약 엔터티를 보내지 않으려 한다면 헤더를 보내지 말아야 한다.

• 서버가 다루거나 사용할 수 없는 큰 엔터티를 서버에게 보내지 않으려는 목적으로만 사용해야 한다.
• 클라이언트는 expect:100을 줘도 마냥 기다리지 말고 일정 시간이 지나면 걍 보내야한다 (그럼 이거 왜 있어요...)

서버와 100 Continue

• 서버가 Expect: 100-continue를 받는다면 100 continue 응답 혹은 에러코드로 답해야한다.
• 서버는 절대로 Expect:100-continue를 보내지 않는 서버에게 100을 주면 안된다.
• 서버가 100을 리턴하기 전에 엔터티를 받았다면 100을 리턴할 필요가 없다
• 서버가 요청을 끝내기로 했다면 서버는 그냥 응답을 보내고 연결을 닫아서는 안된다 -> 클라가 응답을 받을 수 없기 때문
• (대체 뭔소리...?)

 

200-299: 성공 상태 코드

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

POST요청 후 302를 받으면 클라는 Location헤더에 있는 리다이렉트 URL을 GET요청으로 요청한다. 

HTTP/1.1은 혼란을 일으켰다. HTTP/1.1은 이걸 303 상태 코드를 사용한다. (서버는 뒤이어 GET요청이 오도록 POST 요청을 리다이렉션하기 위해 303 상태 코드를 보낼 수 있다.)

이 혼란을 막기 위해 307을 쓰라며 이게 나오게 된 것... 흠...

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

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

 

 

헤더

일반 헤더 (General Headers)

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

Connection , Date, MIMN-Version 등이 있다.

일반 캐시 헤더

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

Cache-Control : 메시지와 함께 캐시 지시자를 전달하기 위해 사용한다

 

요청 헤더

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

From, Host, Referer User-Agent등이 있다.

Accept 관련 헤더

서버에게 자신의 선호와 능력을 알려준다.

Accept : 서버가 보내도 되는 미디어의 종류

Accept-Encoding : 서버가 보내도 되는 인코딩

등등...

조건부 요청 헤더

제약을 넣을 때 사용. 

Expect, If-Match 등등...

요청 보안 헤더

인증을 위한 해더

Authorization, Cookie, Cookie2

프록시 요청 헤더

Max-Forwards : 요청이 원 서버로 향하는 중 프록시나 게이트웨이로 전달 될 수 있는 최대 횟수 (Trace메소드와 함께 사용 된다)

 

 

응답 헤더

클라이언트에게 부가 정보를 제공한다.

Age : 응답이 얼마나 오래 됐는지 (중개자를 통해서 왔음을 암시한다)

Regry-After : 현재 리소스가 사용 불가능한 상태일 때 언제 가능한지 알려줌

등등...

협상 헤더

서버에 프랑스어와 독일어로 번역된 HTML 문서가 있는 경우처럼 여러 표현이 가능한 상황이라면 HTTP/1.1은 어떤 표현을 택할지 협상할 수 있도록 지원한다.

Accept-Ranges : 서버가 지원에 대해 받아들일 수 있는 범위의 형태

Vary : 서버가 확인해 보아야 하고 그렇기 때문에 응답에 영향을 줄 수 있는 헤더들의 목록

응답 보안 헤더

요청 보안이 오면 응답 보안도 있어야겠쥬

Set-Cookie가 대표적

 

엔터티 헤더

요청과 응답 모두 엔터티를 포함할 수 있기 때문에 서버/클라 모두 사용 가능하다.

Allow, Location....

콘텐츠 헤더

Content-Base: 본문에서 사용된 상대 URL을 계산하기 위한 Base Url

Content-Encoding : 본문에 적용된 어떤 인코딩

등등...

엔터티 캐싱 헤더

언제 어떻게 캐시가 되어야 하는지에 대한 지시자를 제공한다.

ETag, Expired, Last-Modified...