HTTP 완벽 가이드
1. HTTP : 웹의 기초
🚩 3장 HTTP 메시지
# HTTP 메시지 : HTTP 애플리케이션간에 주고받은 데이터의 구조화된 블록
# 데이터 블록
- 텍스트 메타 정보 : 메시지의 내용과 의미를 설명
- 데이터 : 선택적으로
3.1 메시지의 흐름
1) 메시지는 원 서버 방향을 인바운드로하여 송신된다.
- 인바운드 : 메시지가 원 서버로 향하는 것
- 아웃바운드 : 모든 처리가 끝난 뒤, 메시지가 사용자 에이전트로 돌아오는 것
2) 다운 스트림으로 흐르는 메시지
- HTTP 메시지는 강물과 같이 흐른다. => 거슬러 올라가지 않는다.
- 모든 메시지는 다운 스트림으로 흐른다.
- 위의 요청에서 프록시1이 프록시2의 업스트림이다.
- 하지만 응답에서는 프록시2의 다운스트림이다.
# 다운 스트림 : 발송자 -> 수신자
# 업 스트림 : 수신자 -> 발송자
3.2 메시지의 각 부분
- 각 메시지는 클라이언트로부터의 요청이나 서버로부터의 응답 중 하나를 포함 -> 응답메시지, 요청메시지
# 요청 메시지 : 웹 서버에 어떤 동작을 요구한다.
# 응답 메시지 : 요청의 결과를 클라이언트에게 돌려준다.- 요청 메시지의 형식
- 시작줄 : <메서드><요청URL><버전> ex) GET www.hyeb.com HTTP/1.0
- 헤더 : <헤더>
- 본문 : <엔티티 본문>- 응답 메시지의 형식
- 시작줄 : <버전><상태코드><사유구절> ex) HTTP/1.0 200 OK
- 헤더 : <헤더>
- 본문 : <엔티티 본문>
1) 시작줄 : 어떤 메시지인지 서술, 줄 단위로 분리된 아스키 문자열, 공백으로 구분
-
메서드 : 클라이언트 측에서 서버가 리소스에 대해 수행해주길 바라는 동작
-
요청 URL : 요청 대상이 되는 리소스를 지칭하는 완전한 url 혹은 url의 경로 구성요소
-
상태코드 : 요청 중에 일어난 일을 설명해주는 세자리의 숫자
- 상태코드 참고
-
사유구절 : 숫자로 된 상태 코드의 의미를 사람이 이해할 수 있게 설명해주는 짧은 문구
- 사유구절 참고 -
버전 : 이 메시지에서 사용 중인 HTTP의 버전
- HTTP/x.y 의 형식, 요청과 응답 메시지 양쪽 모두에 기술된다.
- 대화하는 애플리케이션들에게 대화상대의 능력과 메시지의 형식에 대한 단서를 제공
- x와 y는 분리된 숫자로 다루어진다.
- HTTP/2.22는 HTTP/2.3보다 크다 => 22와 3을 비교해야한다.
2) 헤더 : 이름, ':', 선택적인 공백, 값, CRLF가 순서대로 나타나는 0개 이상의 헤더들
-
일반 헤더 : 요청과 응답 양쪽에 모두 나타날 수 있음
-
요청 헤더 : 요청에 대한 부가 정보를 제공
-
응답 헤더 : 응답에 대한 부가 정보를 제공
-
Entity 헤더 : 본문 크기와 콘텐츠, 혹은 리소스 그 자체를 서술
-
확장 헤더 : 명세에 정의되지 않은 새로운 헤더
3) 본문 : 데이터, 텍스트나 이진테이터를 포함할 수 있음, 필수요소는 아님
3.3 메서드 : 모든 서버가 모든 메서드를 구현하지 않는다.
1) 안전한 메서드 : 사용하는 메서드가 HTTP 요청의 결과로 서버에 어떤 작용도 없다.
- GET이나 HEAD 메서드는 HTTP요청의 결과로 서버에 어떤 작용도 없다.
무조건적인 것은 아니고 개발자에 달렸다... - 왜 사용하는가?
=> 서버에 어떤 영향을 줄 수 있는 메서드가 사용될 때 , 사용자들에게 그 사실을 알려주는 HTTP 애플리케이션을 만들 수 있도록 하는 것
<예시>
1. 사용자가 결제할 때 사용자의 신용카드 정보를 담은 POST 요청이 전송되고, 서버에서는 요청의 작용이 일어난다.
=> 서버에 어떤 영향을 줄 수 있는 메서드가 사용될 때
2. 이 사례에서 '작용' 은 구매로 인해 신용카드로 대금이 청구되는 것을 말한다.
3. 사용자에게 신용카드가 결제된다는것을 알려주는 경고 메시지를 띄운다.
=> 사용자들에게 그 사실을 알려주는 HTTP 애플리케이션을 만들 수 있도록 하는 것
2) GET : 서버에게 리소스를 달라고 요청할 때
3) HEAD : GET처럼 행동하지만 서버는 응답으로 헤더만을 돌려준다. => 엔티티 본문은 반환 X
- 리소스를 가져오지 않고도 그에 대해 무엇인가를 알아낼 수 있다.
- 응답의 상태 코드를 통해 개체가 존재하는지 확인할 수 있다.
- 헤더를 확인하여 리소스가 변경되었는지 검사할 수 있다.
- 서버 개발자들은 반드시 반환되는 헤더가 GET으로 얻는 것과 정확히 일치함을 보장해야한다.
- HTTP/1.1 준수를 위해서는 HEAD 메서드가 만드시 구현되어 있어야한다.
4) PUT : 서버에 문서를 쓴다.
- 서버가 요청의 본문을 가지고 요청 URL의 이름대로 새문서를 만들거나
- 이미 URL이 존재한다면 본문을 사용해서 교체한다.
5) POST : 서버에 입력 데이터를 전송
- HTML 폼을 지원하기 위해 흔히 사용
- 폼에 담긴 데이터는 서버로 전송되고 필요로 하는 곳에 보낸다.
6) TRACE : 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려준다.
- 서버는 자신이 받은 요청 메시지를 본문에 넣어 TRACE 응답을 되돌려준다.
- 클라이언트는 자신과 목적지 서버 사이의 요청/응답 연쇄를 따라가면서
- 자신이 보낸 메시지가 망가졌거나 수정되었는지, 어떻게 변경되었는지 확인할 수 있다.
7) OPTIONS : 웹 서버에게 여러 가지 종류의 지원 범위에 대해 물어본다.
- 리소스에 실제로 접근하지 않고 어떻게 접근하는 것이 최선인지 확인할 수 있는 수단을 클아이언트에 제공
8) DELETE : 서버에게 요청 URL로 지정한 리소스를 삭제요청
- HTTP 명세는 서버가 클라이언트에게 알리지 않고 요청을 무시하는것을 허용한다.
9) 확장 메서드 : HTTP/1.1 명세에 정의되지 않은 메서드
- 어떤 확장 메서드를 정의한다면, 그것은 대부분의 HTTP 애플리케이션이 이해할 수 없을 것이고
- 당신의 HTTP 애플리케이션이 이해할 수 없는 확장 메서드를 사용하는 애플리케이션과 마주칠 수도 있다.
- 확장 메서드를 다룰 때는 "엄격하게 보내고 관대하게 받아들여라" 라는 오랜 규칙에 따르는 것이 좋다.
