참고: https://developer.mozilla.org/ko/docs/Web/HTTP/Messages
HTTP 메시지는 서버와 클라이언트 간에 데이터가 교환되는 방식이다. 메시지에는 클라이언트에서 서버로 전달되는 요청(request)과 서버에서 클라이언트로 전달되는 응답(response)가 있다.
HTTP 메세지는 ASCII로 인코딩된 텍스트 정보이며 여러 줄로 되어있다.
HTTP Request
HTTP Request Message는 Request Line, Message Header, Message Body로 이뤄져있다.
모든 요청은 마지막에 개행을 가지며 Header와 Body 사이에도 개행으로 구분한다.
Request Line
{HTTP Method} {요청 타겟} {HTTP Version}형태를 가지며 요청 메시지의 맨 첫 줄에 위치한다.
HTTP Method
서버가 수행해야 할 동작을 나타내는 부분으로 대체로 GET, POST, PUT, DELETE를 사용한다.
요청 타겟
주로 URL 또는 프로토콜, 포트, 도메인으로 표현되는 절대경로로 나타낼 수 있다.
origin 형식
끝에 ?와 함께 쿼리 문자열이 붙는 절대경로로 가장 일반적인 형식이다.
absolute 형식
완전한 URL 형식으로 프록시에 연결하는 경우 대부분 GET과 함께 사용된다.
authority 형식
도메인 이름과 옵션 포트로 이뤄진 URL로 HTTP 터널을 구축하는 경우 CONNECT와 함께 사용할 수 있다.
asterisk 형식
OPTIONS와 함께 별표 *로 간단하게 서버 전체를 나타낼 때 사용한다.
HTTP Version
Request Line의 마지막은 HTTP Version이 된다. 버전 정보는 메시지의 남은 구조를 결정하므로 응답 메시지에서 써야 할 HTTP 버전을 알려주는 역할을 한다.
Message Header
Header 참고 1: https://www.zerocho.com/category/HTTP/post/5b3ba2d0b3dabd001b53b9db
Header 참고 2: https://gmlwjd9405.github.io/2019/01/28/http-header-types.html
요청에 들어가는 HTTP 헤더는 HTTP 헤더의 기본구조를 따른다. 대소문자 구분없이 문자열 다음에 콜론 :이 붙으며 그 뒤에 오는 값은 헤더에 따라 달라진다.
요청 헤더는 General 헤더, Request 헤더, Entity 헤더로 나눠진다.
General 헤더
General Header 참고 : https://tools.ietf.org/html/rfc2616#page-34
요청과 응답 모두에 적용되지만 바디에서 최종적으로 전송되는 데이터와는 관련이 없는 헤더. Cache-Control, Date, Pragma, Trailer, Transfer-Encoding, Via, Connection, Upgrade, Warning이 General 헤더에 포함된다.
Date
HTTP 메시지를 생성한 일시. 자동으로 만들어진다. Date: Thu, 1 Oct 2019 20:00:00 GMT
Connection
클라이언트와 서버 간 연결에 대한 옵션을 설정. close와 keep-alive값을 가진다.
Connection: close의 경우 현재 HTTP 메시지 직후에 TCP 접속을 끊는다는 것을 의미한다. Connection: keep-alive의 경우 현재 TCP 커넥션을 유지한다는 의미이다.
Request 헤더
HTTP 요청에서 사용되지만 메시지의 컨텐츠와는 관련이 없는 HTTP 헤더이다. Accept, Accept-*, If-*와 같은 요청 헤더는 조건부 요청 수행을 허용하는 Request 헤더이다. 또한, Cookie, User-Agent, Referer은 서버가 응답에 맞출 수 있도록 만들어준다.
Host (필수)
웹 요청에서는 필수적인 요소로 요청하는 호스트에 대한 호스트 명 및 포트번호를 의미한다. (FQDN) HTTP/1.1 이후부터는 Host 필드는 필수적이다. Host 헤더의 존재로 동일 IP 주소를 갖는 단일 서버에 여러 사이트를 구축할 수 있다.(?)
User-Agent
클라이언트 소프트웨어 명칭 및 버전 정보를 가리키는 헤더. 주로 통계적인 목적, 프로토콜 위반 추적, 특정 User Agent 제한으로 응답이 늦어지는 문제를 인식하기 위해 사용된다.
Cookie
클라이언트에게서 넘어오는 쿠키 정보 Cookie: key=value; key2=value2와 같은 형식으로 전달되며 ;을 구분자로 여러 쿠키정보가 들어올 수 있다.
Referer
바로 직전에 머물러 있던 웹 링크 주소 주로 애널리틱스에서 사용됨
Authorization
인증 토큰을 서버로 보낼 때 사용하는 헤더 Authorization: Bearer qjgojwojfwjjpqepwll.11o4jo1jfdwofpwkepkf.fsdkfjo2pk3okr23p와 같이토큰의 종류 + 실제 토큰을 전송한다.
Accept
클라이언트 자신이 원하는 미디어 타입 및 우선순위를 알려주는 헤더. Accept: */*는 모든 미디어 타입이 가능하다는 의미이며 Accept: text/html은 html 파일만 가능하다는 의미이다. Accept 헤더는 HTTP Entity Header 중 Content-Type과 매칭된다.
Accept-Charset
클라이언트가 원하는 문자 집합. Accept 헤더는 HTTP Entity Header 중 Content-Type charset-xxx과 매칭된다.
Accept-Encoding
클라이언트가 원하는 문자 인코딩 방식 Accept 헤더는 HTTP Entity Header 중 Content-Encoding과 매칭된다.
Accept-Language
클라이언트가 원하는 지원 가능한 언어. Accept 헤더는 HTTP Entity Header 중 Content-Language와 매칭된다.
Entity 헤더
Entity 헤더 필드는 Message Body의 컨텐츠를 나타내는 HTTP 헤더로 요청, 응답에 모두 사용된다. Content-Encoding, Content-Language, Content-Length, Content-Location, Content-MD5, Content-Range, Content-Type, Expires, Last-Modified등이 Entity 헤더가 된다.
Message Body
Body는 요청의 마지막 부분에 위칳한다. GET, HEAD, DELETE, OPTIONS 요청과 같이 본문이 없는 요청도 있을 수 있다.
본문은 크게 두 가지 종류로 나뉜다.
단일-리소스 본문: 본문을 나타내는 헤더 두 개 Content-Type과 Content-Length로 정의된 단일 파일
다중-리소스 본문: 멀티파트 본문으로 구성되는 본문으로 파트마다 다른 정보를 지닌다. 보통은 HTML 폼과 관련이 있다.
참고: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#multipartform-data
HTML form 참고 : https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms
HTTP Response
HTTP Response도 Request와 비슷하게 Status Line, Message Header, Message Body로 이뤄진다. 또한 Request와 마찬가지로 마지막은 개행으로 구분하며 Message Header와 Body도 개행으로 구분된다.
Status Line
HTTP 응답의 시작 줄을 일컫는 말이며 {프로토콜 버전} {상태 코드} {상태 텍스트}로 이뤄져 있다. HTTP/1.1 200 OK와 같은 형태를 띈다.
Message Header
Message Header는 요청과 마찬가지 구조를 띈다. 대소문자를 구분하지 않는 문자열 다음에 :으로 구별하며 뒤에 값이 오는 구조로 되어있다. 응답 헤더 또한 General 헤더, Response 헤더, Entity 헤더로 구별할 수 있다. General과 Entity는 Request에서 알아본 것과 동일하다.
Access-Control-Allow-Origin
CORS 문제를 우회할 수 있도록 만든 헤더. 서버에서 응답을 받는 프론트 주소를 위 헤더에 적어주어 문제를 해결할 수 있다. 이때, 프로토콜, 서브도메인, 도메인, 포트 중 하나만 달라도 CORS가 발생하므로 주의가 필요하다.
참고로 CORS 요청시에는 OPTIONS 요청으로 서버가 CORS를 허용하는지 물어본다. 이 때 Access-Control-Request-Method로 실제 보내는 메서드를 알려주고 Access-Control-Request-Headers로 실제 보내는 헤더를 알려준다. 만약 Request와 Allow가 일치하면 CORS요청이 이뤄지게 된다.
Allow
Access-Control-Allow-Methods와 비슷한 헤더이지만 Access-Control-Allow-Methods는 CORS에만 적용되는 반면 Allow는 CORS 외에도 적용된다는 점이 차이점이다. 요청받은 메서드를 지원하지 않는 경우 Allow에 지원하는 메서드를 전달하면서 405 Method Not Allowed를 응답하면 된다.
예를 들어 GET http://localhost:8080/index.html은 지원하지만 POST http://localhost:8080/index.html는 지원하지 않는다면 405 에러와 함께 Allow: GET이 응답으로 나타난다.
Content-Disposition
응답 본문을 브라우저가 어떻게 표시할 지 알려주는 헤더. inline이라면 웹 페이지로 표시되지만 attachment라면 본문이 다운로드된다. 이때 filename옵션으로 다운받는 파일의 이름을 지정할 수 있다.
Location
300번대 응답이나 201 Created의 경우 Location으로 다음 이동할 URL을 지정해주어야한다. (201은 선택사항) 이때 Location은 어느 페이지로 이동해야할 지 알려주는 헤더이다.
Message Body
Request와 동일
