HTTP 완벽 가이드 3장 HTTP 메세지

HTTP 메세지 :  클라이언트, 서버, 프록시 사이를 흐르는 HTTP 어플리케이션 간의 데이터 블록

서버로의 요청은 인바운드   응답으로 되돌아오는것은 아웃바운드

모든 HTTP 메세지는 다운스트림이다  

요청 프록시 1 ->                                                     프록시 1이 요청시엔 프록시 3의 업스트림이지만

프록시 2 ->                                     응답시엔 프록시 3이 프록시 1의 업스트림

프록시 3  ->

서버

프록시 3<-

프록시 2 <-

요청 프록시 1 <-

HTTP메세지는 시작점, 헤더, 본문 으로 구성된다     본문은 없어도된다.

시작점 : 이것이 어떤 메세지인가에 대한 정보가 나타나있음

헤더 : 이 메세지의 속성들 기술

본문 : 이 메세지의 데이터

시작점과 헤더는 문장이 끝날때 줄바꿈 문자열(CRLF)로 끝나야한다    개행 문자열도 가능

Content-type : 본문이 무엇인지 알려줌

Content-length: 본문의 크기를 알려줌

요청 : 서버의 어떤 동작을 요구

응답 : 요청의 결과를 전달

요청 메세지

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

<헤더>

<본문>

응답 메세지

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

<헤더>

<본문>

메소드 : 클라이언트 측에서 서버가 리소스에 대해 이렇게 동작해줬으면하는걸 말함

버전 : HTTP (메이저) / (마이너)   메이저, 마이너 부분 둘다 정수

헤더 : 헤더는 반드시 CRLF(빈줄)로 끝나야함     본문과 구별하기위해

상태 코드 : 클라이언트의 요청에 무슨일이 일어났는지 상태를 나타내는 코드

사유구절 : 상태코드를 인간이 이해하기쉬운 문자로 표현     오로지 인간을 위해서 사용되는것

본문 : 데이터들

본문에 아무것도없어도 CRLF를 해야한다     하지만 사람이 잊을수있기때문에 CRLF가 없어도 받아들일수있도록 호환성을 

갖추어야한다

모든 HTTP 메세지는 시작줄로부터 시작한다 요청 메세지의 시작줄은 무엇을 해야할지 전달하고

응답 메세지의 시작줄은 요청의 결과에대한 정보를 전달한다

요청 메세지의 시작줄 : 서버가 요청URL에 대해 요청 메소드 기능을 수행하기를 요청  HTTP버전도 알려줌

응답 메세지의 시작줄 : HTTP버전과 요청의 결과에 따른 상태코드와 사유구절을 전달 

요청메세지, 응답메세지의 각 필드는 공백으로 구분

메소드 : 서버에게 무엇을 해야하는지 알려줌

HTTP메소드

메서드	설명	메시지 본문
GET	서버에서 어떤 문서를 가져온다.	없음
HEAD	서버에서 어떤 문서에 대해 헤더만 가져온다.	없음
POST	서버가 처리해야 할 데이터를 보낸다.	있음
PUT	서버에 요청 메시지의 본문을 저장한다.	있음
TRACE	메시지가 프락시를 거쳐 서버에 도달하는 과정을 추적한다.	없음
OPTIONS	서버가 어떤 메서드를 수행할 수 있는지 확인한다.	없음
DELETE	서버에서 문서를 제거한다.	없음

모든 서버가 위 메소드들을 다 구현해놓진 않는다

어떤 서버는 위의 메소드에는 없는 확장메소드를 구현해서 사용할수도있다

상태코드 : 클라이언트의 요청에 따른 결과가 어떤지 나타내준다

사유구절이 인간이 보기쉽다면 상태코드 프로그램이 처리하기쉽다

200  == OK

401  == Unauthorized

404  == NotFound

상태코드 분류

전체 범위        정의된 범위        분류

100 - 199         100 - 101         정보 

200 - 299         200 - 206         성공 

300 - 399         300 - 305         리다이렉션 

400 - 499         400 - 415         클라이언트 에러 

500 - 599         500 - 505         서버 에러

실제 정의된범위의 아닌 상태코드의 에러도 그 분류에맞는 의미를 내포하고있어야한다

버전번호 : 요청의 시작점 응답의 시작점 양쪽 다 들어있다 자신의 http프로토콜 버전을 알려준다

어떤 버전이 전해지면 그 버전은 그 어플리케이션의 가장 높은버전이며 그 아래 버전들은 다 이해할수있다

http 헤더필드는 요청과 응답 메세지에 추가정보를 더한다

헤더의 분류

1. 일반 헤더 : 요청과 응답 양쪽 모두에 나타날수있는 헤더

2. 요청 헤더 : 요청에 대한 부가정보를 제공

3. 응답 헤더 : 응답에 대한 부가정보를 제공

4. 엔티티 헤더 : 본문 크기와 콘텐츠 or 리소스 그 자체를 서술

5. 확장 헤더 : 명세에 정의되지않은 새로운 헤더

헤더의 문법

헤더의 예                                                             설명 

Date： Tue, 3 Oct 1997 02:16:03 GMT             서버가응답을만들어 낸 시각 

Content-length： 15040                         15,040바이트의 데이터를 포함한 엔터티 본문 

Content-type： image/gif                             엔터티 본문은 GIF 이미지다. 

Accept： image/gif, image/jpeg, text/html     클라이언트는 GIF, JPEG 이미지와 HTML을 받아들일 수 있다. 

헤더는 보기좋게 줄로 나눌수있다 줄의 맨앞부분은 스페이스바 or tab키의 공백이 와야한다

HTTP/1.0 200 0K 

Content-Type: image/gif 

Content-Length: 8572 

Server: Test Server 

Version 1.0

엔티티 본문

http의 메세지를 전달

안전한 메소드 : 요청을 처리해도 서버에서는 아무일도 일어나지않는 메소드

하지만 꼭 안전한 메소드가 안전을 보장하지는않는다. (쓰는 개발자에게 달렸다)

POST같은 경우에는 사용자의 요청을 처리하기위해서 서버에서 일이 일어난다

안전한 메소드의 목적은 어플리케이션에서 안전하지않은 메소드의 일을 처리할때 그것을 사용자에게 알려주는 어플리케이션을 만드는데 있다

GET

가장 흔히쓰이는 메소드    서버에게 어떤 리소스를 달라고 요청하는것

HEAD

GET과 유사한 메소드 요청을 보내면 응답은 반드시 헤더만 존재해야한다 엔티티본문은 절대 존재해선안된다

내가 요청하는 리소스가 존재하는지 

요청한 리소스에 대한 정보

리소스가 변경되었는지

확인할수있다

GET을 사용했을때 헤더와 반드시 일치해야한다

HTTP /1.1 준수을 위해 서버는 반드시 HEAD메소드를 구현해두어야한다

PUT

서버에 문서를 쓸때 사용한다

문서가 없다면 새 문서

문서가 존재한다면 수정을 한다

POST

서버에 입력한 데이터들을 보낼때 사용

TRACE

서버에게 도착할때까지 내가 보낸 요청에 무슨일있는지 확인할수있는 메소드

주로 진단을 위해 사용한다

요청에 대한 응답은 내가 보낸 요청에 관한 메세지들을 넣어 응답한다

프록시는 POST를 그냥보내지만 TRACE는 메소드를 구별할수없다

어떠한 엔티티본문도 보낼수없다 

TRACE 요청처리를 결정하는것은 중간 어플리케이션이 처리한다

OPTIONS

서버에게 어떤 리소스에대한 접근가능한 메소드들의 정보를 요청할수있다

리소스에 실제 접근하지않아도 그 리소스에 대한 정보를 얻을수있다

DELETE

요청한 리소스를 삭제한다

하지만 삭제를 보장하진못한다 HTTP명세에  서버가 클라이언트의 요청을 무시하는게 가능하도록 되어있다

확장 메소드

HTTP 는 필요에따라 확장해도 문제가 되지않도록 설계되어있으며 새로 기능을추가해도 전혀 문제가되지않는다

메서드                 설명 

LOCK         사용자가 리소스를 잠글 수 있게 해준다. 예를 들어, 문서를 편집하는 동안 다른 사람이 동시에 같은 문서를                 편집 하지 못하도록 문서를 잠글 수 있다. 

MKCOL         사용자가 문서를 생성할 수 있게 해준다.

COPY         서버에 있는 리소스를 복사한다. 

MOVE         서버에 있는 리소스를 옮긴다.

모든 확장 메서드가 형식을 갖춘 명세로 정의된 것은 아니라는 점에 주의

당신의 HTTP 애플리케이션이 이해할 수 없는 확장 메서드를 사용하는 애플리케이션과 마주칠 수도 있다

이런 상황에서는 확장 메서드에 대해 관용적인 것이 최고다

 프락시는，종단 간 (end-to-end) 행위를 망가뜨리지 않을 수 있다면，알려지지 않은 메서드가 담긴 메 시지를 다운스트림 서버로 전달하려고 시도한다. 

그렇지 않다면 프락시는 501 Not Implemented 상태 코드로 응답해야 한다. 확장 메서드(그리고 대부분의 HTTP 확 장)를 다룰 때는 “엄격하게 보내고 관대하게 받아들여라” 라는 오랜 규칙에 따르는 것이 가장 좋다

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

100-199： 정보성 상태 코드

HTTP / 1.1에 도입

복잡함을 감수할 만한 가치가 있는지에 대해 논란이 되고 있다

100     Continue     요청의 시작 부분 일부가 받아들여졌으며, 클라이언트는 나머지를 계속 이어서 보내야 함을 의미한다. 이것을 보낸 후, 서버는 반드시 요청을 받 아 응답해야 한다. 

 101 Switching Protocols 클라이언트가 Upgrade 헤더에 나열한 것 중 하나로 서버가 프로토콜을 바꾸었음을 의미한다

100 Continue는 HTTP 클라이 언 트 애플리케이션이 서버에 엔터티 본문을 전송하기 전에 그 엔터티 본문을 서버가 받아들일 것인지 확인하려고 할 때，그 확인 작업을 최적화하기 위한 의도로 도입

------------------------------------------------------------------------------------------------------------

요청헤더

Accept헤더 : 클라이언트가 무엇을 원하고 무엇을 할수있고 무엇을 원치않는지 알려준다

이 정보를 통해 더 똑똑한 결정을 내릴수있다

헤더                                     설명 

Accept                  서버에게 서버가 보내도 되는 미디어 종류를 말해준다. 

Accept-Charset       서버에게 서버가 보내도 되는 문자집합을 말해준다. 

Accept-Encoding     서버에게 서버가 보내도 되는 인코딩을 말해준다. 

Accept-Language    서버에게 서버가 보내도 되는 언어를 말해준다. 

TEa                      서버에게 서버가 보내도 되는 확장 전송 코딩을 말해준다.

조건부 요청 헤더 : 서버에게 응답을 받기전 어떤 제약을 줄수있다

헤더                         설명 

Expect                  클라이언트가 요청에 필요한 서버의 행동을 열거할 수 있게 해준다. 

If-Match               문서의 엔터티 태그가 주어진 엔터티 태그와 일치하는 경우에만 문서를 가져온다. 

If-Modified-Since    주어진 날짜 이후에 리소스가 변경되지 않았다면 요청을 제한한다. 

If-None-Match       문서의 엔터티 태그가 주어진 엔터티 태그와 일치하지 않는 경우에만 문서를 가져온다. 

If-Range                문서의 특정 범위에 대한 요청을 할 수 있게 해준다. 

If-Unmodified-Since 주어진 날짜 이후에 리소스가 변경되었다면 요청을 제한한다. 

Range                    서버가 범위 요청을 지원한다면，리소스에 대한 특정 범위를 요청한다.

요청 보안 헤더 : 리소스에 접근하기전 인증을 통해 트랜잭션을 좀더 안전하게 만들어줄수있다

프록시 요청 헤더

응답 헤더 : 누가 응답을 보내고있는지 응답자의 능력은 어떻게되는지 알려주며 응답에 대한 특별한 설명도 제공가능