1. 메시지의 흐름

1) 메시지는 원 서버 방향을 인바운드로 하여 송신

클라이언트 -> 서버 : 인바운드 클라이언트 <- 서버: 아웃바운드

2) 메시지는 다운스트림으로 흐른다

모든 메시지(요청, 응답)는 다운스트림으로 흐른다 메시지의 발송자는 수신자의 업스트림이다

2. 메시지의 각 부분

메시지는 시작줄/ 헤더 블록/ 본문 세 부분으로 이루어진다.

시작줄: 어떤 메시지인지 서술
헤더 블록: 속성
본문: 데이터 (존재하지 않을 수 있다)

시작줄과 헤더는 줄 단위로 분리된 아스키 문자열. 각 줄은 캐리지 리턴(ASCII 13)과 개행 문자(ASCII 10)으로 구성된 두 글자의 줄바꿈 문자열로 끝난다(CRLF). 잘못만들어진 HTTP 어플리케이션은 캐리지 리턴과 개행 문자 모두를 항상 전송하지는 않는다.
엔티티 본문이나 메시지 본문은 텍스트나 이진 데이터를 포함할 수 있다.

1) 메시지 문법

모든 HTTP 메시지는 요청 메시지나 응답 메시지로 분류된다. 요청 메시지: 웹 서버에 동작 요구

<메서드> <요청 URL> <버전>
<헤더>

<엔터티 본문>

응답 메시지: 요청의 결과를 클라이언트에게 돌려줌

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

<엔터티 본문>

2) 메서드: 클라이언트 측에서 서버가 리소스에 대해 수행해주길 바라는 동작

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

HTTP는 쉽게 확장할 수 있도록 설계되어서 서버가 추가 메서드를 구현할 수도 있다. 이런 메서드는 HTTP 명세를 확장하는 것이므로 확장 메서드라고 불린다
모든 서버가 모든 메서드를 구현하지는 않는다. HTTP 1.1과 호환되는 서버는 GET, HEAD만 구현해도 된다.

안전한 메서드

HTTP는 안전한 메서드라 불리는 메서드의 집합을 정의한다. GET과 HEAD 사용하는 요청의 결과는 서버에 어떤 작용도 없으므로 안전하다.
안전한 메서드가 서버에 작용을 유발하지 않는다는 보장은 없다.
목적은 서버에 어떤 영향을 줄 수 있는 안전하지 않은 메서드가 사용될 때 사용자에게 그 사실을 알려주는 HTTP 애플리케이션을 만들 수 있도록 하는 것에 있다.

😲 메서드 차이 요약

안전 - 호출해도 리소스를 변경하지 않는다
멱등 - 여러번 호출해도 결과가 똑같다 PUT은 결과를 대체하므로 같은 요청을 여러번 해도 최종 결과가 같지만 POST는 두 번 호출하면 같은 리소스가 두 번 서버에 저장될 수 있다 -> 자동 복구 매커니즘에 활용 (서버가 TIMEOUT 등으로 정상 응답을 못 주었을 때 클라이언트가 같은 요청을 다시해도 되는가)
캐시 가능 - 응답 결과 리소스를 캐시해서 사용해도 되는가 보통 GET, HEAD를 캐시로 사용

3) 요청 URL

요청 대상이 되는 리소스를 지칭하는 완전한 URL(혹은 리소스를 가리키는 절대 경로)

4) 버전

이 메세지에서 사용중인 HTTP 버전. 요청과 응답 메시지 모두에 기술된다.
HTTP로 대화하는 애플리케이션들에게 대화 상대의 능력과 메시지의 형식에 대한 단서를 제공해주기 위한 것이다.
어떤 애플리케이션이 지원하는 가장 높은 HTTP 버전을 가리킨다. (응답을 보낸 애플리케이션이 해당 버전까지 이해할 수 있음)
HTTP/<메이저>.<마이너> 의 형식이다. 메이저와 마이너는 모두 정수이고, 버전을 비교할 때는 메이저 마이너 숫자는 각각 분리된 숫자로 다루어진다. (예. HTTP 2.22 < HTTP 2.3>)

5) 상태 코드: 요청 중에 무엇이 일어났는지 설명하는 세 자리 숫자. 첫번째 자릿 수는 상태의 일반적인 분류를 나타낸다.

전체 범위	정의된 범위	분류
100 - 199	100 - 101	정보
200 - 299	200 - 206	성공
300 - 399	300 - 305	리다이렉션
400 - 499	400 - 415	클라이언트 에러
500 - 599	500 - 505	서버 에러

100-109: 정보성 상태 코드

상태코드	사유구절	의미
100	Continue	요청의 시작 부분 일부가 받아들여졌고, 클라이언트는 나머지를 이어서 보내야 한다.
101	Switching Protocols	클라이언트가 Upgrade 헤더에 나열한 것 중 하나로 서버가 프로토콜을 바꾸었다.

200-299: 성공 상태 코드

상태코드	사유구절	의미
⭐ 200	OK	요청은 정상이고, 엔터티 본문은 요청된 리소스를 포함하고 있다.
⭐ 201	Created	서버 개체를 생성하라는 PUT과 같은 요청을 위한 것. 응답은 생성된 리소스에 대한 참조가 담긴 Location 헤더와 URL을 엔티티 본문에 포함.
⭐ 202	Accepted	요청은 받아들여졌으나 서버는 아직 어떤 동작도 수행하지 않았다. 배치 처리 같은 곳에서 사용
203	Non-Authoritative Information	엔터티 헤더가 원래 서버가 아닌 리소스의 사본에서 왔다.
⭐ 204	No Content	웹브라우저를 새 문서로 이동시키지 않고 갱신하고자 할 때 사용. 응답 메시지는 헤더와 상태줄을 포함하지만 엔터티 본문에는 보낼 데이터가 없다. 예. 문서 편집기의 save
205	Reset Content	브라우저에게 현재 페이지에 있는 HTML 폼에 채워진 모든 값을 비우라고 한다.
206	Partial Content	부분 혹은 범위 요청이 성공했다.

300-399: 리다이렉션 상태 코드

클라이언트가 관심있어 하는 리소스에 대해 다른 위치를 사용하라고 말해주거나, 다른 대안 응답을 제공할 때 사용. (보통 Location 헤더와 함께)
리소스에 대한 애플리케이션의 로컬 복사본이 원래 서버와 비교했을 때 유효한지 확인하기 위해서도 사용.

상태코드	사유구절	의미
300	Multiple Choices	클라이언트가 동시에 여러 리소스를 가리키는 URL 을 요청한 경우, 그 리소스의 목록과 함께 반환한다. 잘안씀.
301	Moved Permanently	요청한 URL이 옮겨졌을 때 사용한다.
302	Found	301 상태코드와 같지만, 클라이언트는 location 헤더로 주어진 URL을 리소스를 임시로 가리키기 위한 목적으로 사용하고, 이후 요청은 원래 URL을 사용해야한다.
303	See Other	리소스를 다른 URL에서 가져와야 한다고 말해줄 때 쓰인다.
⭐ 304	Not Modified	헤더를 이용해 조건부 요청을 만들 수 있다. 클라이언트가 GET과 같은 조건부 요청을 보냈고, 리소스가 최근에 수정되지 않았다면 이 코드는 리소스가 수정되지 않음을 의미한다. 캐시를 목적으로 사용 (클라이언트가 로컬PC에 저장된 캐시를 재사용)
305	Use Proxy	리소스가 반드시 프락시를 통해서 접근되어야 함을 나타내기 위해 사용한다.
307	Temporary Redirect	301 상태코드와 같지만, 클라이언트는 location 헤더로 주어진 URL을 리소스를 임시로 가리키기 위한 목적으로 사용해야한다. 이후 요청에서는 원래 URL을 사용해야 한다.

🤔 300번대 응답 코드들의 차이를 잘 모르겠습니다!

Permanent Redirects: 301, 308

리소스가 영구적으로 옮겨졌을 때. 리소스를 새로운 주소로 옮겼거나 HTTP로 접속시 HTTPS로 옮길 때. 308을 사용할 때는 새 위치에 동일한 요청을 보내야하고, 301을 사용할 때는 HTTP 메서드를 변경할 수 있다. (예. POST 요청을 했는데 308 응답을 받으면, 클라이언트는 새 위치로 POST 요청을 보내야한다. 반대로 301 응답을 받으면 GET 요청으로 바꿔서 보낼 수 있다.) 308이 나온지 얼마 되지 않아서(2015년 4월 RFC 7538) 모든 브라우저가 지원하진 않으므로 보통 301을 사용하는 것이 좋다.

Temporary Redirects: 302, 303, and 307

리소스가 임시로 새 주소로 옮겨졌을 때. 리다이렉트의 수명이 제한되어 있고, 보통 캐시되면 안된다. 예를 들어 웹사이트가 점검중이라 사용자들에게 해당 시간 동안 "점검중" 페이지로 리다이렉트할 때 사용. 혹은 사용자의 지역, 시간대, 디바이스 별로 리다이렉트할 때 사용. HTTP/1.0은 이런 경우 302 코드만 존재했었다. 원래는 메소드를 바꾸면 안되는데 보통은 GET 메소드로 새 URL로 요청을 보냈다. 그래서 HTTP/1.1에서 303, 307을 도입했다. 301, 308의 차이와 비슷하게 303은 항상 새 URL에 GET 요청을, 307은 기존 메서드를 그대로 사용해 요청해야한다. 302, 303이 같은 역할을 한다고 보면 된다. 303을 권장하지만 많은 애플리케이션이 302를 기본값으로 사용. POST가 반복되어야할 때는 307 사용

참고자료: https://www.drlinkcheck.com/blog/http-redirects-301-302-303-307-308

400-499: 클라이언트 에러 상태 코드

클라이언트가 잘못된 요청을 보냈을 때 사용. 똑같은 재시도는 실패함.

상태코드	사유구절	의미
⭐ 400	Bad Request	잘못된 요청. 요청 구문, 메세지 등 오류
⭐ 401	Unauthorized	클라이언트에게 인증(예.로그인)하라고 요구하는 내용의 응답을 적절한 헤더와 함께 반환(WWW-Authenticate과 함께 인증 방법 설명)
402	Payment Required	현재 쓰이지 않는다.
⭐ 403	Forbidden	요청이 서버에 의해 거부되었음을 알려주기 위해 사용. 주로 접근 권한이 없을 때 사용
⭐ 404	Not Found	요청한 URL을 찾을 수 없음을 알려주기 위해 사용
405	Method Not Allowed	지원하지 않는 메서드로 요청을 받았을 때 사용
406	Not Aceeptable	클라이언트는 매개변수로 어떤 종류의 엔터티를 받아들이고자 하는지 명시할 수 있다. 이 코드는 리소스 중 클라이언트가 받아들일 수 없는 것이 있을 때 사용.
407	Proxy Authentication Required	401 상태코드와 같으나, 리소스에 대해 인증을 요구하는 프락시 서버를 위해 사용한다.
408	Request Timeout	요청을 완수하기에 시간이 너무 많이 걸리는 경우, 서버는 408 코드를 반환하고 응답하고 연결을 끊을 수 있다
409	Confilct	요청이 리소스에 대해 일으킬 수 있는 몇몇 충돌을 지칭하기 위해 사용
410	Gone	리소스가 제거됨을 알려준다. 404와 비슷하나 서버가 한때 그 리소스를 가지고 있었다는 점이 다르다
411	Length Required	서버가 요청 메시지에 content-length 헤더가 있을 것을 요구한다.
412	Precondition Failed	조건부 요청을 했는데 그중 하나가 실패했을 때 사용한다.
413	Request Entity Too Large	한계의 크기를 넘은 요청을 클라이언트가 보냈을때
414	Request URI Too Long	한계의 길이를 넘은 요청 url 이 포함된 클라이언트가 보냈을때
415	Unsupported Media Type	서버가 이해하거나 지원하지 못하는 내용 유형의 엔터티를 클라이언트가 보넀을 때 사용
416	Requested Range Not Satisfiable	요청 메시지가 리소스의 특정 범위를 요청했는데, 그 범위가 잘못되었거나 맞지 않을때
417	Expectation Failed	요청에 포함된 expect 요청 헤더에 서버가 만족시킬 수 없는 기대가 담겨있는 경우 사용

500-599: 서버 에러 상태 코드

클라이언트가 올바른 요청을 보냈음에도 서버 자체에서 에러가 발생했을 때 사용. 재시도하면 성공할 수 있음.
클라이언트가 서버의 제한에 걸렸거나, 게이트웨이 리소스와 같은 서버 구성요소에서 발생한 에러도 포함.

상태코드	사유구절	의미
⭐ 500	Internal Server Error	서버가 요청을 처리할 수 없게 만드는 에러를 만났을 때 사용
501	Not Implemented	클라이언트가 서버의 능력을 넘은 요청을 했을 때 (지원하지 않는 메서드 등)
502	Bad Gateway	프락시나 게이트웨이같은 서버가 요청 응답 연쇄에 있는 다음 링크로부터 가짜 응답에 맞닥뜨렸을 때. (예.부모 게이트웨이에 접속하는 것이 불가능할 때)
⭐ 503	Service Unavailable	현재는 서버가 요청을 처리할 수 없지만 나중에는 가능함을 의미. Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수 있음.
504	Gateway Timeout	408과 비슷하지만 응답을 기다리다 타임아웃이 발생한 게이트웨이나 프락시에서 온 응답이라는점이 다르다.
505	Http Version Not Supported	지원하지 않으려고 하는 버전의 프로토콜로 된 요청을 받았을 때.

+참고) 많이 쓰이는 상태 코드들 https://www.restapitutorial.com/httpstatuscodes.html 를 참고하자 (별표가 되어있는 상태 코드들)

6) 사유 구절

숫자로 된 상태 코드의 의미를 사람이 이해할 수 있게 설명해주는 짧은 문구. 상태 코드 이후부터 줄꿈 문자열까지.
상태코드와 일대일로 대응된다.

7) 헤더

요청과 응답 메시지에 추가 정보를 더한다. 이름/값 쌍의 목록이다.
이름 + : + 선택적인 공백 + 값 + CRLF 가 순서대로 나타나는 0개 이상의 헤더들. (예시: Accept: image/gif, image/jpeg) 헤더의 목록은 CRLF로 끝나서 엔터티 본문의 시작을 표시한다(본문이 없더라도 항상 CRLF로 끝난다). 몇몇 버전의 HTTP는 요청이나 응답에 어떤 특정 헤더가 포함되어야만 유효한 것으로 간주한다.

일반 헤더: 클라이언트와 서버가 모두 사용. (예. Date)

헤더	설명
Connection	클라이언트와 서버가 요청/응답 연결에 대한 옵션을 정할 수 있게 해준다
Date	메세지가 언제 만들어졌는지에 대한 시간
MIME-Version	발송자가 사용한 MIME의 버젼을 알려준다
Transfer-Encoding	수신자에게 안전한 전송을 위해 어떠한 인코딩이 적용되었는지 알려준다
Upgrade	발송자가 업그레이드 하길 원하는 프로토콜 버젼
Via	어떤 중개자로부터 왔는지 알려준다
Cache-Control	메세지와 함께 캐시 지지자를 전달하기 위해 사용

요청 헤더: 요청 메시지를 위한 헤더. 서버에게 클라이언트가 받고자 하는 데이터 타입이 무엇인지와 같은 부가 정보를 제공한다. (예. Accept)

Accept 관련 헤더: 클라이언트가 무엇을 원하고 원치않는지, 무엇을 할 수 있는지
조건부 요청 헤더: 요청에 제약을 넣을 때
요청 보안 헤더: 리소스에 접근하기 전 클라이어트가 자신을 인증하게 한다
프락시 요청 헤더: 프락시 기능을 돕기 위한 헤더

헤더	설명
Client-IP	클라이언트가 실행된 컴퓨터의 IP 주소
From	클라이언트 사용자의 메일 주소
⭐ Host	요청의 대상이 되는 서버의 호스트 명과 포트. 요청에서 필수. 하나의 서버가 여러 도메인을 처리해야할 수 있으므로.
Referer	현재의 요청 URI가 들어있었던 문서의 URL을 제공
User-Agent	요청을 보낸 어플리케이션의 이름을 서버에게 알려준다
Accept	서버가 보내도 되는 미디어 종류를 알려준다
Accept-Charset	서버가 보내도 되는 문자집합을 알려준다
Accept-Encoding	서버가 보내도 되는 인코딩을 말해준다
Accept-Language	서버가 보내도 되는 언어를 말해준다
Tranfer-Encoding	서버가 보내도 되는 확장 전송 코딩을 말해준다
Except	클라이언트가 요청에 필요한 서버의 행동을 열거할 수 있게 해준다
If-Modified-Since	주어진 날짜 이후에 리소스가 변경되지 않았다면 요청을 제한한다
Range	서버가 범위 요청을 지원한다면, 리소스에 대한 특정 범위를 요청한다
Authorization	클라이언트가 서버에게 제공하는 인증 그 자체에 대한 정보를 담고 있다
Cookie	클라이언트가 서버에게 토큰을 전달할 때 사용한다
Cookie2	요청자가 지원하는 쿠키의 버젼을 알려줄 때 사용한다
Max-Forwards	요청이 원 서버로 향할 때 다른 프락시나 게이트웨이로 전달될 수 있는 최대 횟수. TRACE와 함께 사용

응답 헤더: 응답 메시지를 위한 헤더. (예: Server)

협상 헤더: 서버가 협상 가능한 리소스에 대한 정보를 담는 헤더.
응답 보안 헤더

헤더	설명
Age	응답이 얼마나 오래되었는지
Public	서버가 특정 리소스에 대해 지원하는 요청 메서드의 목록
Retry-After	현재 리소스가 사용 불가능한 상태일 때, 언제 가능한지 알려주는 날짜 혹은 시간
Server	서버 애플리케이션에 대한 이름과 버젼
Title	HTML 문서에서 주어진 것과 같은 제목
Warning	자세한 경고 메시지
Vary	서버가 확인해 보아야하고 그렇기 때문에 응답에 영향을 줄 수 있는 헤더들의 목록
Accept-Ranges	서버가 자원에 대해 받아들일 수 있는 범위의 형태
Proxy-Authenticate	프락시에서 클라이언트로 보낸 인증요구의 목록
Set-Cookie	서버가 클라이언트를 인증할 수 있도록 클라이언트 측에 토큰을 설정하기 위해 사용
Set-Cookie2	서버에서 클라이언트로 보낸 인증요구의 목록
WWW-Authenticate	서버에서 클라이언트로 보낸 인증요구의 목록

엔터티 헤더: 엔터티 본문에 대한 헤더. 본문의 크기, 콘텐츠, 리소스 등의 정보를 알려준다. (예. Content-Type)

콘텐츠 헤더: 콘텐츠에 대한 구체적인 정보 제공
엔티티 캐싱 헤더: 언제 어떻게 엔터티가 캐싱되어야하는지 정보 제공

헤더	설명
Allow	이 엔티티에 대하여 수행할 수 있는 요청 메서드들
Location	클라이언트에게 해당 엔티티가 실제로 어디있는지 알려주는 헤더
Content-Encoding	본문에 적용된 인코딩
Content-Length	본문의 길이나 크기
Content-Location	리소스가 실제 어디에 위치하는지
Content-Range	전체 리소스에서 이 엔티티가 해당하는 범위를 바이트 단위로 표현
Content-Type	이 본문이 어떤 종류의 객체인지
Expires	이 엔티티가 유효하지 않을 때 원본을 다시 받아와야 하는 일시
Last-Modified	가장 최근 이 엔터티가 변경된 일시

확장 헤더

애플리케이션 개발자들에 의해 만들어졌지만 아직 승인된 HTTP 명세에 추가되지 않은 비표준 헤더.

🤗 실제 HTTP 메시지 헤더를 구경하자

네이버 메인 화면을 접속했을 때

Remote Address: 클라이언트 IP
Referrer Policy: https://developer.chrome.com/blog/referrer-policy-new-chrome-default

Effective-Java-Camp / http-the-definitive-guide

[1부 3장] HTTP 메시지 #3