HTTP 메세지
HTTP 메세지는 HTTP 애플리케이션 간에 주고 받은 데이터의 블록이다.
블록들은 메세지의 내용과 의미를 설명하는 텍스트 메타 정보로 시작하고 다음에는 선택적으로 데이터가 올 수 있다.
인 바운드
, 아웃 바운드
, 업스트림
, 다운 스트림
은 메세지의 방향을 의미하는 용어이다.
메세지는 원 서버 방향을 인바운드로 하여 송신한다.
메세지가 원 서버로 향하는 것은 인바운드
로 이동하는것 이고, 모든 처리가 끝난 뒤에 메세지가 사용자 에이전트로 돌아오는 것은 아웃바운드
로 이동하는 것 이다.
다운 스트림으로 흐르는 메세지
HTTP 메세지는 강물과 같이 흐른다, 요청 메세지나 응답 메세지나 관계없이 모든 메세지는 다운 스트림으로 흐른다.
메세지의 각 부분
HTTP 메세지는 단순한, 데이터의 구조화 된 블럭이다.
메세지는 시작줄
, 헤더 블록
, 본문
이렇게 세 부분으로 이루어진다.
시작줄은 이 메시지가 어떤 메시인지 서술하며, 헤더 블록은 메시지 속성, 본문은 데이터를 담고 있거나 안담고 있을 수 도 있다.
각 구간은 줄바꿈 물자열 CRLF
로 끝난다.
메세지 문법
모든 HTTP 메세지는 요청 메세지
, 응답 메세지
로 분류된다.
요청 메세지
요청 메세지는 서버에 어떤 동작을 요구하는것을 말한다.
요청 메세지의 형식은 다음과 같이 생겼다
<메서드> <요청URL> <버전>
<헤더>
<엔티티 본문>
메서드
클라이언트 측에서 서버가 리소스에 대해 수행해주길 바라는 동작이다.
GET
, HEAD
, POST
와 같은것들이 메서드다.
요청 URL
요청 대상이 되는 리소스를 지정하는 완전한 URL 혹은 URL의 경로 구성요소다.
버전
이 메세지에서 사용중인 HTTP 버전이다.
응답 메세지
응답 메세지는 요청의 결과를 클라이언트에게 돌려주는것을 말한다.
<버전> <상태코드> <사유 구절>
<헤더>
<엔티티 본문>
상태코드
요청 중에 무엇이 일어났는지 설명하는 세 자리 숫자다.
각 코드의 첫 번째 수는 상태의 일반적인 분류(성공
, 실패
, 에러
등)를 나타낸다.
사유 구절
숫자로 된 상태 코드의 의미를 사람이 이해할 수 있게 설명해주는 짧은 구문
사유 구절은 오로지 사람에게 읽히기 위한 목적으로만 존재한다.
헤더들
이름, 콜론(:), 선택적인 공백, 값 CRLF가 순서대로 나타나는 0개 이상의 헤더들, 이 헤더의 목록은 빈 줄(CRL)로 끝나 헤더 목록의 끝과 엔티티 본문의 시작을 표시한다.
엔티티 본문
엔터티 본문은 임의의 데이터 블록을 포함한다.
모든 메세지가 엔터티 본문을 포함하는것은 아니므로 떄떄로 메세지는 CRLF으로 끝나게 된다.
시작줄
모든 HTTP 메세지는 시작줄로 시작한다.
요청줄
요청 메세지의 시작줄, 혹은 요청줄에서는 서버에서 어떤 동작이 일어나야 하는지 설명해주는 메서드
와 그 동작에 대한 대상을 지칭하는 URL
, 클라이언트가 어떤 HTTP 버전으로 말하고 있는지 서버에 알려주는 HTTP 버전
도 포함한다.
응답줄
응답 메세지는 수행 결과에 대한 상태 정보와 결과 데이터를 클라이언트에게 돌려준다.
응답 메세지의 시작줄은 혹은 응답줄에는 응답 메세지에 쓰인 HTTP 버전
, 숫자로 된 상태코드
, 상태코드 텍스트
들어있다.
메서드
모든 서버가 모든 메서드를 구현해둔건 아니다.
안전한 메서드(Safe Method)
GET
, HEAD
메서드는 안전하다고 할 수 있는데, 이는 GET이나 HEAD메서드를 사용하는 HTTP 요청의 결과로 서버에 어떤 작용도 없음을 의미한다.
안전한 메서드가 서버에 작용을 유발하지 않는다는 보장은 없지만 안전한 메서드의 목적은, 서버에 어떤 영항을 줄 수 있는 안전하지 않는 메서드가 사용될 때 사용자들에게 그사실을 알려주는 HTTP 애플리케이션을 만들 수 있도록 하는 것 에 있다.
GET
GET메서드는 가장 흔히 쓰이는 메서드다.
주로 서버에게 리소스를 달라고 요청할 때 쓰인다.
HEAD
HEAD 메서드는 정확히 GET처럼 행동하지만, 서버는 응답으로 헤더만 돌려주고 엔티티 본문은 결코 반환하지 않는다.
HEAD 메서드를 이용하면 ,
- 리소스를 가져오지 앟고도 그에 대해 무엇인가(타입이라거나)를 알아 낼 수 있다.
- 응답의 상태 코드를 통해, 개체가 존재하는지 확인 할 수 있다.
- 헤더를 확인하여 리소스가 변경되었는지 검사 할 수 있다.
PUT
PUT메서드의 의미는, 서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 이미 URL이 존재한다면 본문을 사용해서 체하는 것이다.
POST
POST 메서드는 서버에 입력 데이터를 전송하기 위해 설계되었다.
TRACE
TRACE 메서드는 주로 진단을 위해 사용된다.
예를 들면 요청이 의도한 요청/응답 연쇄를 거쳐가는지 검사할 수 있다. 또한 프록시나 다른 애플리케이션들이 요청에 어떤 영향을 미치는지 확인해보기 좋은 도구다.
프락시는 POST요청을 바로 서버로 통과 시키는 반면 GET 요청은 웹 캐시와 같은 다른 HTTP 애플리케이션으로 전송한다.
OPTIONS
OPTIONS 메서드는 웹 서버에게 여러 가지 종류의 자원 범위에 대해 물어본다.
서버에게 특정 리소스에 대해 어떤 메서드가 지원되는지 물어 볼 수 있다.
DELTE
DELTE 메서드는 서버에게 요청 URL로 지정한 리소스를 삭제 요청한다.
그러나 클라이언트는 삭제가 수행되는것을 보장하지 못한다.
확장메서드
확장 메서드는 HTTP/1.1 명세에 정의되지 않은 메서드다.
개발자들에게 그들의 서버가 구현한 HTTP 서비스의 서버가 관리하는 리소스에 대한 능력을 확장하는 수단을 제공한다.
상태코드
HTTP 상태 코드는 크게 다섯가지로 나뉜다.
상태코드는 클라이언트에게 그들의 트랜잭션을 이해할 수 있는 쉬운 방법을 제공한다.
100-199: 정보성 상태 코드
정보성 상태 코드는 HTTP/1.1에서 도입되었다.
상태코드 | 사유구절 | 의미 |
---|---|---|
100 | Continue | 요청의 시작 부분 일부가 받아짐, 클라이언트는 나머지를 계속 보내야함. |
101 | Switching Protocols | 클라이언트가 Upgrade헤더에 나열한 것 중 하나로 서버가 프로토콜을 바꾸었음을 의미 . |
100Continue는 HTTP 클라이언트 애플리케이션이 서버에 엔티티 본문을 전송하기 전에 그 엔티티 본문을 서버가 받아 들일것인지 확인할때, 그 확인 작업을 최적하기 위한 의도로 도입된 것이다.
200-299: 성공 상태 코드
클라이언트가 요청을 보내면, 그 요청은 대게 성공한다. 서버는 대응하는 성공을 의미하는 상태 코드의 배열을 갖고 있으며, 각각 다른 종류의 요청에 대응한다.
상태코드 | 사유구절 | 의미 |
---|---|---|
200 | OK | 요청은 정상적이고, 엔티티 본문은 요청된 리소스에 포함하고 있다. |
201 | Created | 서버 개체를 생성하라는 요청(예: PUT)을 위한것. 서버는 상태코드를 보내기전에 반드시 객체를 생성해야함 |
202 | Accepted | 요청은 받아들여졌으나 서버는 아직 그에 대한 어떤 동작도 수행하지 않았으며 서버가 완료한다는 보장도없음. |
203 | Non_Authoriative Information | 엔터티 헤더에 들어있는 정보가 원래 서버가 아닌 리소스의 사본에서 왔다. |
204 | No Content | 응답 메세지는 헤더와 생태줄을 포함하지만 엔티티 본문은 포함하지 않는다. |
205 | Reset Content | 주로 브라우저를 위해 사용되는 또 하나의코드, 브라우저에게 현재 페이지에 있는 HTML 폼에 채워진 모든값을 비우라는 의미 |
206 | Partical Content | 부분 혹은 범위 요청이 성공했다. |
300-399: 리다이렉션 상태 코드
리다이렉션 상태 코드는 클라이언트가 관심있어 하는 리소스에 대해 다른 위치를 사용하라고 말해주거나 그 리소스의 내용 대신 다른 대안 응답을 제공한다.
리다이렉션 상태 코드중 일부는 리소스에 대한 애플리케이션의 로컬 복사본이 원래 서버와 비교했을 때 윻한지 확인하기 위해 사용됨.
상태코드 | 사유구절 | 의미 |
---|---|---|
300 | Multiple Choices | 클라이언트가 동시에 여러 리소스를 가리키는 URL을 요청했을 경우 그 리소스의 목록을 함꼐 반환함. 사용자는 이중에서 택함. |
301 | Moved Pemanently | 요청한 URL이 옮겨졌을 때 사용한다. 응답은 Location 헤더에 혀재 리소스가 존재하고 있는 URL을 포함해야함. |
302 | Found | 301과 같음. 그러나 Location헤더로 주어진 URL을 리소스를 임시로 가리키기 위한 목적으로 사용해야함. |
303 | See other | 클라이언트에게 리소스를 다른 URL에서 가져와야 한다고 말해주기 위해 쓰임. |
304 | Not Modified | 클라이언트가 GET과 같은 조건부 요청을 보냈고 그 리소스가 최근에 수정된 일이 없을떄 쓰임. |
305 | Use Proxy | 리소스가 반드시 프락시를 통해 접근되야함을 나타냄. |
400-499: 클라이언트 에러 상태 코드
클라이언트는 서버가 다룰 수 없는 무언가를 보낸다.
잘못 구성된 요청 메시지 같은 것이 있을수 있으며, 가장 흔한 것은 존재하지 않는 URL에 대한 요청이다.
상태코드 | 사유구절 | 의미 |
---|---|---|
400 | Bad Request | 클라이언트가 잘못된 요청을 보냈다고 말해준다. |
401 | Unautorized | 리소스를 얻기전에 클라이언트에게 스스로를 인증하라고 요구하는 내용의 응답을 적절한 헤더와 함께 반환. |
403 | Forbidden | 요청이 서버에 의해 거부되었음을 알려주기위해 사용. 그러나 이코드는 보통 서버가 거절의 이유를 숨길때 주로 사용함. |
404 | Not Found | 서버가 요청한 URL을 찾을 수 없음을 알려주기 위해 사용함. |
405 | Method Not Allowed | 요청한 URL에 대해 지원하지 않는 메소드로 요청받았을때 사용함. |
408 | Time Out | 클라이언트 요청을 완수하기에 시간이 너무 많이 걸리는 경우에 사용함. |
409 | Contifict | 요청의 리소스에 대해 일으킬 수 있는 몇몇 충돌을 지칭하기 위해 사용. |
410 | Gone | 404와 비슷하나 리소스를 갖고 있다는 점이 다르다. 주로 웹사이트를 유지보수하면서 서버 관리자가 클라이언트에게 리소스가 제거 된 것을 알려주기 위해 사용 |
500-599: 서버 에러 상태 코드
클라이언트가 올바른 요청을 보냈음에도 서버 자체에서 에러가 발생할 수 있다.
이것은 클라이언트가 서버의 제한에 걸린 것 일수 있고 혹은 게이트웨이 리소스와 같은 서버의 보조 구성요소에서 발생한 에러일 수 도 있다.
상태코드 | 사유구절 | 의미 |
---|---|---|
500 | Internal Server Error | 서버가 요청을 처리 할 수 없게 만드는 에러를 만났을 때 사용 |
501 | Not Implemented | 클라이언트가 서버의 능력을 넘는 요청을 했을때 사용 |
502 | Bad Gateway | 프락시나 게이트웨이처럼 행동하는 서버가 그 요청 응답 연쇄에 있는 다음 링크로부터 가짜 응답에 맞닥뜨렸을때. |
503 | Service Unavaliable | 현재는 서버가 요청을 처리해줄 수 없지만 나중에는 가능함을 의미할때 사용. |
504 | Gateway Timeout | 404와 비스하지만 프락시에서 온 응답이라는 점이 다름. |
505 | HTTP Version Not Supported | 서버가 지원 할 수 없거나 지원하지 않으려고 하는 버전의 프로토콜 된 요청을 받았을때 사용. |
헤더
헤더와 메서드는 클라이언트와 서버가 무엇을 하는지 결정하기 위해 함께 사용된다.
헤더에는 특정 종류의 메세지만 사용 할 수 있는 헤더
, 더 일반 목적으로 사용 할 수 있는 헤더
, 그리고 응답과 요청 메세지 양쪽 모두에서 정보를 제공하는 헤더가
있다.
일반 헤더
일반 헤더는 클라이언트와 서버 양쪽 모두가 사용한다.
클라이언트, 서버 그리고 어딘가에 메세지를 보내는 다른 애플리케이션들을 위해 다양한 목적으로 사용된다.
요청헤더
요청 헤더는 요청 메시지를 위한 헤더이다.
서버에게 클라이언트가 받고자 하는 데이터 타입이 무엇인지와 같은 부가 정보를 제공한다.
Accept 관련 헤더
클라이언트는 Accept관련 헤더들을 이용해 서버에게 자신의 선호와 능력을 알려 줄 수 있다.
즉 클라이언트가 무엇을 원하고 무엇을 원하는지 알려줄 수 있음.
요청 보안 헤더
HTTP는 자체적으로 요청을 위한 간단한 인증요구/응답 체계를 갖고있다.
그것은 요청하는 클라이언트가 어느정도의 리소스에 접근하기 전에 자신을 인증하게 함으로서 트랜잭션을 약간 더 안전하게 만들 수 있다.
응답 헤더
응답메세지는 그들만의 응답 헤더를 갖는다.
응답 헤더는 클라이언트에게 부가 정보를 제공함.
엔티티 헤더
엔티티 헤더란 엔티티 본문에 대한 헤더를 말한다 이 헤더는 양쪽 모두 사용할 수 있다.
예를들어 엔티티 본문에 들어있는 데이터 타입이 무엇인지 등을 말해 줄 수 있다.
엔티티 정보헤더
콘텐츠 헤더
엔티티 캐싱 헤더
일반 캐싱 헤더는 언제 어떻게 캐시가 되어야 하는지에 대한 지시자를 제공하지만.
엔티티 캐싱 헤더는 엔티티 캐싱에 대한 정보를 제공한다.
'book review > HTTP 완벽 가이드' 카테고리의 다른 글
[HTTP 완벽 가이드] 7장 캐시 (0) | 2024.05.12 |
---|---|
[HTTP 완벽가이드] 5장 웹 서버 (0) | 2024.05.12 |
[HTTP 완벽 가이드] 4장 HTTP 커넥션 (0) | 2024.05.12 |
[HTTP 완벽 가이드] 2장 URL과 리소스 (0) | 2024.05.12 |