HTTP 완벽가이드 - HTTP 메시지
04 Jan 2018 | HTTP3장 HTTP 메시지
3.1 메시지의 흐름
- 인바운드 : 클라이언트에서 서버
- 아웃바운드 : 서버에서 클라이언트
3.2 메시지의 각 부분
3.2.1 메시지 문법
- 요청 메시지 형식
<메서드> <요청 URL> <버전>
<헤더>
CRLF(빈줄)
<엔터티 본문> - 응답 메시지 형식
<버전> <상태 코드> <사유 구절>
<헤더>
CRLF(빈줄)
<엔터티 본문>
메서드
클라이언트 측에서 서버가 리소스에 대해 수행해주길 바라는 동작
요청 URL
요청 대상이 되는 리소스를 지칭하는 완전한 URL 혹은 URL의 경로
버전
이 메시지가 사용 중인 HTTP의 버전
상태 코드
요청 중에 무엇이 일어났는지 설명하는 세 자리의 숫자
사유 구절(reason-phrase)
숫자로 된 상태 코드의 의미를 사람이 이해할 수 있게 설명해주는 짧은 문구
상태 코드 이후부터 줄바꿈 문자열까지가 사유 구절
오로지 사람에게 잃히기 위한 목적으로 존재
헤더들
이름,콜론(:), 선택적인 공백, 값, CRLF가 순서대로 나타나는 0개 이상의 헤더들. 헤더의 목록은 빈 줄(CRLF)로 끝나 헤더 목록의 끝과 엔터티 본문의 시작을 표시한다.
엔터티 본문
엔터티 본문은 임의의 데이터 블록을 포함한다.
3.2.2 시작줄
모든 HTTP 메시지는 시작줄로 시작한다.
메서드
메서드 | 설명 | 메시지 본문이 있는가 ? |
GET | 서버에 어떤 문서를 가져온다 | 없음 |
HEAD | 서버에서 어떤 문서에 대해 헤더만 가져온다 | 없음 |
POST | 서버가 처리해야 할 데이터를 보낸다 | 있음 |
PUT | 서버에 요청 메시지의 본문을 저장한다 | 있음 |
TRACE | 메시지가 프록시를 거쳐 서버에 도달하는 과정을 추적한다 | 없음 |
OPTIONS | 서버가 어떤 메서드를 수행할 수 있는지 확인한다 | 없음 |
DELETE | 서버에서 문서를 삭제한다 | 없음 |
상태 코드
상태 코드는 클라이언트에게 무슨일이 일어났는지 알려준다
전체 범위 | 정의된 범위 | 분류 |
100 - 199 | 100-101 | 정보 |
200 - 299 | 200-206 | 성공 |
300 - 399 | 300-305 | 리다이렉션 |
400 - 499 | 400-415 | 클라이언트 에러 |
500 - 599 | 500-505 | 서버 에러 |
사유 구절
버전 정보
버전 정보는 어떤 애플리케이션이 지원하는 가장 높은 HTTP 버전을 가리킨다.
버전 번호는 버전의 각 숫자는 분리된 숫자로 다루어 진다. HTTP/2.22는 HTTP/2.3보다 높은 버전이다
3.2.3 헤더
헤더의 분류
- 일반 헤더 : 요청과 응답 양쪽에 모두 나타날 수 있음
- 요청 헤더 : 요청에 대한 부가 정보를 제공
- 응답 헤더 : 응답에 대한 부가 정보를 제공
- Entity 헤더 : 본문의 크기와 콘텐츠, 혹은 리소스 그 자체를 서술
- 확장 헤더 : 명세에 정의되지 않은 새로운 헤더
헤더를 여러 줄로 나누기
긴 헤더 줄은 그들을 여러 줄로 쪼개서 더 읽기 좋게 만들 수 있는데, 추가 줄 앞에는 최소 하나의 스페이스 혹은 탭 문자가 와야 한다
HTTP/1.0 200 OK
Content-Type: image/gif
Content-Length: 8572
Server: Test Server
Version 1.0
3.2.4 엔터티 본문
엔터티 본문은 HTTP 메시지의 화물이라고 할 수 있다.
3.3 메서드
3.3.1 안전한 메서드(Safe Method)
안전한 메서드를 요청 하였을 때 서버에서는 아무런 변경이 일어나지 않음을 이야기 한다.
안전한 메서드의 목적은, 서버에 어떤 영향을 줄 수 있는 안전하지 않은 메서드가 사용될 때 사용자들에게 그 사실을 알려주는 HTTP 애플리케이션을 만들 수 있도록 하는 것이다.
3.3.2 GET
서버에게 리소스를 달라고 요청하기 위해 쓰인다.
3.3.3 HEAD
GET 유사하지만 엔터티 본문을 받지 않는다.
- 리소스를 가져오지 않고도 그에 대해 무엇인가(타입)를 알아낼 수 있다.
- 응답의 상태 코드를 통해, 개체가 존재하는지 확인할 수 있다.
- 헤더를 확인하여 리소스가 변경되었는지 검사할 수 있다.
서버 개발자들은 반드시 반환되는 헤더가 GET으로 얻는 것과 일치함을 보장해야 한다. 또한 HTTP/1.1준수를 위해 HEAD 메서드가 반드시 구현되어 있어야 한다.
3.3.4 PUT
PUT 메서드의 의미는, 서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 이미 URL이 존재한다면 본문을 사용해서 교체하는 것이다.
3.3.5 POST
POST 메서드는 서버에 입력 데이터를 전송하기 위해 설계되었다.
3.3.6 TRACE
클라이언트가 어떤 요청을 할 때, 그 요청은 방화벽, 프락시, 게이트웨이등의 애플리케이션을 통과한다. TRACE 메서드는 주로 진단을 위해서 사용되며 HTTP 애플리케이션에 메서드를 다르게 처리한다. TRACE 요청을 어떻게 처리할지 는 중간 애플리케이션이 결정을 내린다.
3.3.7 OPTIONS
OPTIONS 메서드는 웹 서버에게 여러 가지 종류의 지원 범위에 대해 물어본다. 서버에게 특정 리소스에 대해 어떤 메서드가 지원되는지 물어 볼 수 있다.
3.3.8 DELETE
DELETE 메서드는 리소스 삭제를 요청한다.
Comments