메시지는 소포와 같다. 어떻게 메시지를 만들고 이해하는지 알아보자
- 메시지 흐름
- HTTP 메시지 구조
- 메서드
- 상태 코드
- HTTP 헤더
메시지 흐름
HTTP 메시지는 HTTP 애플리케이션 간에 주고받는 데이터의 블록들이다. 이 메시지는 클라이언트, 서버, 프락시 사이를 흐른다.
메시지의 방향
요청과 응답은 인바운드와 아웃바운드로 이동한다.
✅ 서버는 메시지를 인바운드(Inbound)한다.
✅ 클라이언트로 메시지를 아웃바운드(Outbound)한다.
메시지의 흐름
요청, 응답 상관없이 모든 메시지는 다운스트림으로 흐른다.
✅ 메시지는 다운스트림이다.
✅ 메시지는 결코 업스트림으로 흐르지 않는다.
✅ 발송자는 수신자의 업스트림이다.
인바운드, 아웃바운드, 업스트림, 다운스트림 메시지의 방향을 의미한다.
HTTP 메시지 구조
HTTP 메시지는 구조화된 블록이다. 시작줄, 헤더 블록, 본문 이렇게 세 부분으로 이루어진다.
HTTP/1.0 200 OK ===> 시작줄
Content-type: text/plain ===> 헤더
Content-length: 19
Hi I'm a message! ===> 본문| 영역 | 설명 |
|---|---|
| 시작줄 | 어떤 메시지인지 서술 |
| 헤더 블록 | 메시지 속성 |
| 빈칸 | |
| 본문 | 메시지의 데이터 |
HTTP 명세에 따르면, 각 줄은 CRLF로 끝난다. 견고한 애플리케이션은 그냥 개행 문자도 받아들일 수 있어야 한다.
메시지 문법
모든 메시지는 요청과 응답으로 분류된다.
- 요청 메시지는 어떤 동작을 서버에게 요구
- 응답 메시지는 요청의 결과를 반환
✅ 요청 메시지의 형식은 다음과 같다.
<Method> <URL> <Version>
<Header>
<Entity body>✅ 응답 메시지의 형식은 다음과 같다.
<Version> <Status code> <Reason phrase>
<Header>
<Entity body>요청과 응답은 시작줄만 다르다.
Method
서버의 동작을 요구한다. 'GET', 'POST'와 같이 한 단어로 되어있다.
URL
요청 리소스를 지칭한다.
완전한 URL이 아닌 경로 구성요소라고 해도, 클라이언트가 서버와 대화 중이면 대체로 문제가 없다.
Version
메시지가 사용 중인 HTTP의 버전이다.
HTTP/<메이저 번호>.<마이너 번호>Status code
응답 결과에 대해 설명하는 세 자리 숫자이다. 첫 번째 자릿수는 성공, 실패 등을 나타낸다.
Reason phrase
사유 구절은 오로지 사람에게 읽히기 위한 목적으로 존재한다. 예를 들어 사유 구절이 '완료'와 '완료되지 않음' 이어도 상태 코드가 200이라면 성공을 의미한다.
✅ 아래 목록은 모두 성공을 의미한다.
- HTTP/1.0 200 OK
- HTTP/1.0 200 NOT OK
Header
이름, 콜론(:), 선택적 공백, 값, CRLF를 순서대로 표기한다. 헤더는 빈 줄로 끝나고 본문이 시작된다.
Content-type: text/plain
(공백)
<Entity body>HTTP/1.1과 같은 몇몇 버전은 요청이나 응답에 특정 헤더가 포함되어야만 유효한 것으로 간주한다.
Entity body
임의의 데이터 블록을 포함하며 모든 메시지가 엔티티 본문을 갖지는 않는다.
------------------------------- -------------------------------
GET /test/hi-there.txt HTTP/1.0 <--- 시작줄 ---> HTTP/1.0 200 OK
------------------------------- -------------------------------
Accept: text/* Content-type: text/plain
Accept-Language: en,fr <--- 헤더 ---> Content-length: 19
------------------------------- -------------------------------
본문 ---> Hi I'm a message!
-------------------------------헤더나 엔티티 본문이 없더라도 헤더의 집합은 항상 빈 줄(CRLF)로 끝나야 한다.
시작줄
모든 HTTP 메시지의 시작이다.
✅ 요청 메시지의 시작줄은 무엇을 해야하는지 설명한다.
✅ 응답 메시지의 시작줄은 무슨 일이 일어났는지 설명한다.
요청 메시지의 시작줄
# 요청줄은 "<Method> <URL> <HTTP Version>"으로 구성된다.
GET /test/hi-there.txt HTTP/1.0요청 메시지의 시잘줄, 혹은 요청줄은 메서드와 URL 그리고 HTTP 버전이 기재된다.
- 메서드를 통해 서버에게 동작을 요구한다.
- URL은 동작의 대상이 되는 리소스이다.
- 어떠한 HTTP 버전으로 소통하지 기재한다.
모든 필드는 공백(' ')으로 구분한다.
응답 메시지의 시작줄
# 응답줄은 "<HTTP Version> <Status code> <Phrase reason>"으로 구성된다.
HTTP/1.0 200 OK응답 메시지의 시작줄, 혹은 응답줄은 상태 정보와 결과를 돌려준다.
- 현재 소통중인 HTTP 버전이 나온다.
- 상태 코드는 응답 결과에 숫자 코드이다.
- 사유 구절은 응답 결과에 대해 설명한다.
메서드
요청줄은 메서드로 시작한다. 예를 들어 'GET /text/hi-there.txt HTTP/1.0'의 메서드는 'GET'이다. 참고로 메서드에 따라 본문이 없을 수 있다.
| 메서드 | 설명 | 본문 유무 |
|---|---|---|
| GET | 서버에서 리소스를 가져온다. | 없음 |
| POST | 서버가 처리해야 할 데이터를 보낸다. | 있음 |
| PUT | 서버에 본문을 저장한다. | 있음 |
| PATCH | 서버에 있는 특정 리소스의 일부분만 수정한다. | 있음 |
| DELETE | 서버에 있는 리소스를 삭제한다. | 없음 |
| HEAD | 서버에 있는 리소스의 헤더만 가져온다. | 없음 |
| OPTIONS | 서버가 어떤 메서드를 수행할 수 있는지 확인한다. | 없음 |
모든 서버가 메서드 전체를 구현한 것은 아니다. 예를 들어, HTTP/1.0 버전은 'GET', 'POST', 'HEAD' 메서드만 존재한다.
상태 코드
클라이언트 요청의 결과이다. 상태 코드는 응답줄에 위치한다.
HTTP/1.0 200 OK
...
# 이 응답 메시지의 상태 코드는 200이다.사유 구절은 사람에게 읽히는 한편, 상태 코드는 프로그램이 에러를 처리하기 쉽다. 아래는 상태 코드의 종류이다.
| 전체 범위 | 정의된 범위 | 분류 |
|---|---|---|
| 100~199 | 100~101 | 정보 |
| 200~299 | 200~206 | 성공을 의미 |
| 300~399 | 300~305 | 리소스가 옮겨졌음을 의미 |
| 400~499 | 400~415 | 클라이언트에서 뭔가 잘못되었음을 의미 |
| 500~599 | 500~505 | 서버에서 뭔가 잘못되었음을 의미 |
만약 인식할 수 없는 상태 코드 즉, 확장된 상태 코드를 받는다면 일반 범주에 포함된 구성원으로 가정하고 다루어야 한다. 예를 들어, 515를 받게 된다면, 그 응답을 5xx 메시지들과 마찬가지로 서버 에러로 간주한다.
사유 구절
응답줄의 마지막 구성요소로 상태 코드를 설명한다.
HTTP/1.0 200 OK
...
# 이 응답 메시지의 사유 구절은 'OK'이다.사유 구절은 상태 코드와 일대일로 대응된다. 상태 코드와 반대로 개발자들에게 요청 중 무슨 일이 발생했는지 알려주기 위해 사용된다.
HTTP 명세에는 사유 구절에 대해 엄격한 규칙을 제공하지 않는다.
버전 번호
'HTTP/x.y' 형식으로 요청과 응답 모두에 기술된다. 버전 번호는 HTTP 애플리케이션들이 따르는 프로토콜의 버전을 전달하기 위한 수단이다.
HTTP로 통신하는 애플리케이션들이 상대의 능력과 메시지 형식에 대한 단서를 제공한다. 예를 들어, HTTP/1.1을 사용하는 애플리케이션이 HTTP/1.2를 사용하는 상대방의 기능을 사용할 수 없다.
헤더
HTTP 헤더 필드는 요청과 응답 메시지에 추가 정보를 더한다. 헤더는 기본적으로 이름/값 쌍의 목록이다.
Content-length: 19헤더 분류
애플리케이션은 자유롭게 자신만에 헤더를 만들 수 있다.
- 일반 헤더: 요청과 응답 양쪽에 모두 나타날 수 있음
- 요청 헤더: 요청에 대한 부가 정보를 제공
- 응답 헤더: 응답에 대한 부가 정보를 제공
- Entity 헤더: 본문 크기와 콘텐츠, 혹은 리소스 그 자체를 서술
- 확장 헤더: 명세에 정의되지 않은 새로운 헤더
| 헤더의 예 | 설명 |
|---|---|
| Date: Tue, 3 Oct 1997 02:16:03 GMT | 서버가 응답을 만들어 낸 시각 |
| Content-length: 19 | 19바이트의 엔티티 본문 |
| Content-type: image/gif | 엔티티 본문은 GIF 이미지 |
| Accept: image/gif, image/jpeg, text/html | 클라이언트는 GIF, JPEG, HTML을 받아들일 수 있음 |
헤더 가독성 향상 시키기
헤더를 여러 줄로 나누어 표현할 수 있다. 다음 줄 앞에 최소 하나의 스페이스 또는 탭 문자가 와야 한다.
HTTP/1.0 200 OK
Server: Test Server
Version 1.0
...
# 여러 줄로 쪼개진 Server 헤더, 값은 'Test Server Version 1.0'이다.엔터티 본문
HTTP 엔터티 본문은 선택적이며 이미지, HTML 등 여러 종류의 디지털 데이터를 실어 나를 수 있다.
HTTP/1.0 200 OK
Content-length: 12
Hello world!
# 이 응답 메시지의 엔터티 본문은 'Hello world!'이다.메서드
이전에 봤던 표에 열거된 HTTP 메서드에 대해 자세히 알아보자
✅ 모든 서버는 모든 메서드를 구현하지 않는다.
✅ 메서드는 서버 설정에 의해 구현된다.
| 메서드 | 설명 | 본문 유무 |
|---|---|---|
| GET | 서버에서 리소스를 가져온다. | 없음 |
| POST | 서버가 처리해야 할 데이터를 보낸다. | 있음 |
| PUT | 서버에 본문을 저장한다. | 있음 |
| PATCH | 서버에 있는 특정 리소스의 일부분만 수정한다. | 있음 |
| DELETE | 서버에 있는 리소스를 삭제한다. | 없음 |
| HEAD | 서버에 있는 리소스의 헤더만 가져온다. | 없음 |
| OPTIONS | 서버가 어떤 메서드를 수행할 수 있는지 확인한다. | 없음 |
안전한 메서드(Safe Method)
GET과 HEAD 메서드는 안전하다고 할 수 있는데, 요청이 서버에 어떠한 영향도 주지 않기 때문이다. 즉, 안전한 메서드는 서버의 상태를 변경하지 않는 메서드를 말한다.
안전한 메서드가 서버의 상태를 변경하지 않는다는 보장은 없다.(사실 이는 개발자에게 달린 문제이다.) 안전한 메서드의 목적은 서버에 가해지는 영향에 따라 사용자에게 알려줄 수 있도록 만들기 위함에 있다.
GET
서버에게 리소스를 달라고 요청하기 위해 쓰이는 메서드이다.
# 요청
GET /aws/2023/10/15/aws-app-runner.html HTTP/1.1
Host: boy672820.github.io
Accept: *
# 응답
HTTP/1.1 200 OK
Content-type: text/html
Content-length: 5060
<HTML>
...HEAD
HEAD 메서드는 헤더만을 반환한다.
- 가져오려는 리소스의 정보를 알아낼 수 있다.
- 리소스 존재를 확인할 수 있다.
- 헤더를 통해 리소스가 다른 경로로 이동되었는지 등을 검사할 수 있다.
HEAD 메서드를 통해 반환하는 헤더 값들이 GET과 일치함을 보장해야 한다.
# 요청
HEAD /aws/2023/10/15/aws-app-runner.html HTTP/1.1
Host: boy672820.github.io
Accept: *
# 응답
HTTP/1.1 200 OK
Content-type: text/html
Content-length: 5060PUT
PUT 메서드는 서버에 리소스를 입력하기 위해 사용된다.
# 요청
PUT /hello-world.text HTTP/1.1
Host: boy672820.github.io
Content-type: text/plain
Content-length: 12
Hello world!
# 응답
HTTP/1.1 201 Created
Location: https://boy672820.github.io/hello-world.text
Content-type: text/plain
Content-length: 12
Hello world!엔터티 본문은 요청 URL의 이름을 추적하여 작성되며, 이미 해당 URL 이름에 리소스가 존재할 경우 교체한다.
POST
POST 메서드는 서버에 데이터를 전송하기 위해 설계되었다. 실제로, HTML 폼을 지원하기 위해 사용된다. 전송된 데이터는 서버에서 필요로 하는 곳에 사용된다.(예를 들면, 외부 서버에 데이터를 보낸다든지)
PUT 메서드와 POST 메서드의 차이점은 URL에 있다. PUT 메서드는 URL에 지정된 리소스를 기준으로 데이터를 입력한다. 그러나 항상 리소스의 정확한 위치를 알 수 없기 때문에 POST 메서드를 사용하여 리소스를 생성할 수 있다.
TRACE
TRACE 메서드는 주로 진단을 위해 사용된다. 내가 보내고자 하는 요청이 서버에서 어떻게 받아들여 지는지 진단한다.
- 의도한대로 요청/응답이 되고 있는지 확인한다.
- 프락시나 다른 애플리케이션이 요청에 어떤 영향을 미치는지 확인한다.
HEAD와 마찬가지로 엔터티 본문은 포함할 수 없다.
OPTIONS
OPTIONS 메서드는 서버에게 지원 범위를 물어본다. 예를 들어 서버에게 특정 리소스가 어떤 메서드를 지원하는지 물어볼 수 있다.
# 요청
OPTIONS * HTTP/1.1
Host: boy672820.github.io
Accept: *
# 응답
HTTP/1.1 200 OK
Allow: GET, POST, PUT, OPTIONS서버에 실제로 접근하지 않고도 접근하는 최선에 수단을 클라이언트 애플리케이션에게 제공한다.
axios 라이브러리는 요청 전 OPTIONS 메서드로 사전 요청을 보낸다. 이를 통해 해당 리소스가 지원하는 메서드를 확인한다.
DELETE
요청 URL로 지정된 리소스를 삭제한다. 그러나 클라이언트에게 삭제가 수행되는 것을 보장하지 못한다. 이러한 이유는 HTTP 명세에 서버가 클라이언트 요청을 무시하는 것을 허용하기 때문이다.
# 요청
DELETE /hello-world.text HTTP/1.1
Host: boy672820.github.io
# 응답
HTTP/1.1 200 OK
Content-type: text/plain상태 코드
HTTP 상태 코드는 크게 다섯 가지로 나뉜다. 상태 코드의 각 분류와 사유 구절에 대해 알아보자
| 전체 범위 | 정의된 범위 | 분류 |
|---|---|---|
| 100~199 | 100~101 | 정보 |
| 200~299 | 200~206 | 성공을 의미 |
| 300~399 | 300~305 | 리소스가 옮겨졌음을 의미 |
| 400~499 | 400~415 | 클라이언트에서 뭔가 잘못되었음을 의미 |
| 500~599 | 500~505 | 서버에서 뭔가 잘못되었음을 의미 |
사유 구절을 정확히 어떻게 써야하는지에 대한 가이드는 없음
100~199: 정보성
| 상태 코드 | 사유 구절 | 설명 |
|---|---|---|
| 100 | Continue | 엔터티 본문을 보내기 전 요청이 시작되었음을 의미 |
| 101 | Switching Protocols | 서버가 프로토콜을 바꾸었음을 의미(클라이언트가 Upgrade 헤더에 나열한 것 중 하나) |
100 Continue의 경우 서버가 엔터티 본문을 받아들이기 위한 최적화를 의도로 설계되었다. 클라이언트는 나머지 엔터티 본문을 계속 보내야 한다.
200~299: 성공
말 그대로 요청이 성공되었음을 의미하며, 각각의 요청에 따라 성공 상태 코드로 대응한다.
| 상태 코드 | 사유 구절 | 설명 |
|---|---|---|
| 200 | OK | 요청 URL이 가리키는 리소스를 엔터티 본문에 포함한다. |
| 201 | Created | 서버 개체가 생성되었음을 의미한다. 응답을 반환하기 전에 리소스를 생성해야 하며, 엔터티 본문에 생성된 리소스의 정보를 반환한다. 리소스의 위치는 Location 헤더 값이다.(참조) |
| 202 | Accepted | 요청은 받아들여졌으나 그에 대한 어떤 동작도 수행되지 않았으며, 완료에 대한 보장도 없다. 엔터티 본문 은 요청에 대한 상태와 완료 예정(또는 그에 대한 정보를 얻을 수 있는 URL) 을 포함해야 한다. |
| 204 | No Content | 성공하였으나 반환할 데이터가 없을 때 사용된다. 웹 페이지에서 현재 페이지를 벗어나지 않아도 된다는 것을 의미한다. 예를 들어, 문서 편집기의 "저장 후 계속 편집"에 해당한다. |
| 205 | Reset Content | 주로 브라우저 위해 사용되며, 현재 페이지의 폼에 모든 값을 비우라고 말한다. |
| 206 | Partial Content | 리소스의 일부분을 가져오기 위해 사용된다.(이를 위한 특별한 헤더가 사용 됨) Content-Rage와 Date 헤더를 반드시 포함해야 하며, Etag와 Content-Location 중 하나의 헤더도 반드시 포함해야 한다. |
300~399: 리다이렉션
리다이렉션 상태 코드는 요청한 리소스에 대해 변경된 위치를 알려주거나, 요청할 수 있는 다른 대안으로 응답할 때 사용된다. 선택적으로 변경된 리소스의 위치를 Location 헤더를 통해 알려준다.
또다른 용도는 특정 리소스가 원래 서버와 비교했을 때 유효한지 확인하기 위해 사용된다. 예를 들어, 리소스가 여전히 최신 버전을 유지하고 있는지 혹은 수정되었는지 검사할 수 있다. 이때 If-Modified-Since 헤더를 보내어 특정 날짜 이후에 수정되었는지 확인한다. If-Modified-Since에 기재된 날짜 이후 변경이력이 없다면, 서버는 콘텐츠 대신 304 상태 코드로 응답한다.
브라우저는 304 상태 코드를 확인하여 로컬 복사본을 보여준다.
리다이렉션 상태 코드는 리다이렉트될 URL 링크와 설명을 포함시키는 것이 좋은 관습이다.
| 상태 코드 | 사유 구절 | 설명 |
|---|---|---|
| 300 | Multiple Choices | 요청 가능한 응답이 두 개 이상 있음을 의미한다. 클라이언트는 하나를 선택해야 한다. |
| 301 | Moved Permanently | 요청한 리소스가 Location 헤더에 URL로 이동되었음을 의미한다. |
| 302 | Found | 요청한 리소스가 Location 헤더에 URL로 임시로 이동되었음을 말한다. 해당 리소스는 추후 다른 URL로 변경될 것이며, 때문에 향후에도 같은 URL로 요청해야 알 수 있다. |
| 303 | See Other | 요청한 리소스 자체에 연결되지 않고 다른 URL에서 확인할 수 있다. 다른 URL은 Location 헤더에서 확인할 수 있다. PUT 또는 POST 응답으로 리소스의 위치를 알려주기 위함이다. |
| 304 | Not Modified | 캐시를 목적으로 요청한 리소스가 변경되지 않았음을 나타낸다. |
| 305 | Use Proxy | 리소스가 반드시 프락시를 통해 접근되어야 함을 나타낸다. 프락시 위치는 Location 헤더에서 확인할 수 있다. |
| 307 | Temporary Redirect | 302와 같지만 HTTP 메서드와 엔터티 본문을 변경하지 않고 리다이렉트 요청 하도록 보장한다. |
302 상태 코드의 경우 POST 요청을 보내고 Location 헤더에 담긴 URL을 GET 요청으로 따라갈 것이다.(원래 의도인 POST 요청과 다르게 말이다.) 이에 경우, 본래 사용하던 메서드를 이용하여 리다이렉트할 경우는 307이 적절하다.
400~499: 클라이언트 에러
서버는 잘못된 요청의 경우 4xx 상태 코드를 응답한다. 이를 통해 클라이언트는 잘못 구성된 요청 메시지를 수정하여 재요청하게 된다.
| 상태 코드 | 사유 구절 | 설명 |
|---|---|---|
| 400 | Bad Request | 잘못된 요청은 요청 메시지의 구성이 서버가 의도한 바와 다를 경우를 말한다. 클라이언트는 400 상태 코드를 응답 받았음에도 불구하고 요청을 동일한 형태로 다시 보내서는 안된다. |
| 401 | Unauthorized | 특정 리소스는 적절한 인증을 요구할 수 있다.(이는 서버의 구성에 달려있다.) |
| 403 | Forbidden | 인증을 하였음에도 사용자에 따라 접근할 수 있는 리소스가 있다. 적절한 권한이 없다면 403 상태 코드로 응답하며, 요구하는 내용을 본문에 포함시킬 수 있다.(그러나 보통 서버가 거절 이유를 숨기고 싶을 때 사용된다.) |
| 404 | Not Found | 서버가 요청한 URL에 해당하는 리소스를 찾을 수 없을 때 사용된다. |
| 405 | Method Not Allowed | 지원하지 않는 메서드로 요청 받았을 때 사용된다. 서버는 해당 리소스가 사용 가능한 메서드 가 무엇인지 Allow 헤더를 통해 반드시 알려주어야 한다. |
| 406 | Not Acceptable | 콘텐츠 협상 헤더(Accept 등)에 부합한 리소스가 없을 경우 사용된다. |
| 407 | Proxy Authentication Required | 401 상태 코드와 같으나, 프락시 서버를 위해 사용된다. |
| 408 | Request Timeout | 요청을 완수하기에 시간이 너무 오래 걸리는 경우에 사용된다. 최대 요청 시간은 서버마다 다르다. |
| 409 | Conflict | 요청한 리소스에 대하여 현재 상태와 충돌이 발생할 때 사용된다. 예를 들어 PUT 메서드가 충돌이 발생할 가능성이 가장 높은데, 가령 업로드하려는 파일이 너무 오래되어 서버의 최신 버전인 파일에 덮으쓰려고 할 때 버전 충돌 문제가 발생할 수 있다. |
| 410 | Gone | 404와 비슷하나, 과거 요청한 리소스를 가지고 있었고 제거되었음을 알려주기 위해 사용된다. |
| 411 | Length Required | 서버가 요청 헤더에 Content-length를 포함할 것을 요구할 때 사용된다. |
| 412 | Precondition Failed | 클라이언트가 조건부 요청을 했는데 그중 하나가 실패했을 때 사용된다.(조건부 요청은 Expect 헤더를 사용했을 때 발생한다.) |
| 413 | Request Entity Too Large | 요청 메시지가 서버가 처리할 수 있는(혹은 처리하고자 하는) 크기 가 넘었을 때 사용된다. |
| 414 | Request URI Too Long | 요청 URL이 서버가 처리할 수 있는 크기가 넘었을 때 사용된다. |
| 415 | Unsupported Media Type | 서버가 지원하지 않는 유형의 엔터티 타입을 보냈을 때 사용된다. |
| 416 | Requested Range Not Satisfiable | 요청 메시지가 리소스의 특정 범위를 잘못 지정했을 때 사용된다. |
| 417 | Expectation Failed | 조건부 요청을 서버가 만족시키지 못할 경우 사용된다. |
| 422 | Unprocessable Content | 요청한 콘텐츠 타입을 이해했고 엔터티도 유효하지만, 요청에 포함된 명령을 처리할 수 없을 때 사용된다. |
500~599: 서버 에러
클라이언트가 올바른 요청을 보냈음에도 불구하고 서버 자체에서 에러가 발생하는 경우가 있다. 프락시는 클라이언트 입장에서 서버와 대화할 때 자주 에러를 만나게 된다. 프락시는 문제를 설명하기 위해 5xx 서버 에러 코드를 생성한다.
| 상태 코드 | 사유 구절 | 설명 |
|---|---|---|
| 500 | Internal Server Error | 서버가 요청을 처리할 수 없을 때 사용된다.(서버 내부에서) |
| 502 | Bad Gateway | 프락시나 게이트웨이 역할을 하는 서버가 업스트림 서버로부터 잘못된 응답을 받았을 때 사용된다. |
| 503 | Service Unavailable | 서버가 현재는 요청을 처리해 줄 수 없지만 추후 가능함을 의미한다. Retry-After 헤더를 통해 언제 그 리소스를 사용할 수 있는지 명시한다. |
| 504 | Gateway Timeout | 프락시나 게이트웨이 역할을 하는 서버가 시간안에 업스트림 서버로부터 응답을 받지 못했을 때 사용된다. |
헤더
헤더와 메서드는 클라이언트와 서버가 무엇을 하는지 결정하기 위해 사용된다. 표준 HTTP 헤더와 HTTP/1.1 명세(RFC 2616)에 정의되지 않는 몇몇 헤더에 대해 알아보자
일반 헤더(General Headers)
일반 헤더는 클라이언트와 서버 양쪽에서 다양한 목적으로 사용한다.
# Date 헤더는 서버와 클라이언트를 가리지 않고 메시지가 만들어진 일시를 지칭한다.
Date: Sun, 11 Dec 2023 11:58:00 GMT요청 헤더(Request Headers)
요청 메시지에서 사용한다. 서버에게 받고자 하는 데이터의 타입이 무엇인지와 같은 부가 정보를 제고한다.
# Accept 헤더는 클라이언트가 받아들일 수 있는 미디어 타입 명시한다.
Accept: */*응답 헤더(Response Headers)
응답 헤더는 클라이언트에게 정보를 제공하기 위해 사용된다.
# Server 헤더는 클라이언트에게 nginx서버 1.21.7버전을 사용하고 있음을 알려준다.
Server: nginx/1.21.7엔터티 헤더(Entity Headers)
엔터티 본문에 대한 헤더를 말한다. 예를 들어 엔터티 본문의 데이터 타입이 무엇인지 말해 줄 수 있다.
# Content-type 헤더는 엔터티 본문이 utf-8 문자셋의 HTML 문서임을 알려준다.
Content-type: text/html; charset=utf-8확장 헤더(Extension Headers)
확장 헤더는 개발자들에 의해 자유롭게 만들어진다. 주로 HTTP 명세에 승인되지 않은 비표준 헤더다.
HTTP 프로그램은 확장 헤더가 비표준 이더라도 전달해야 할 필요가 있다.
일반 헤더
일반 헤더는 기본적인 정보를 제공한다.
| 헤더 | 설명 |
|---|---|
| Connection | 클라이언트와 서버 간 연결에 대한 옵션을 정할 수 있다. 예를 들어, 현재 전송이 완료 된 후에도 네트워크 연결을 유지할지 제어한다.(keep-alive) |
| MIME-Version | 발송자가 사용한 MIME 버전을 알려준다. |
| Transfer-Encoding | 수신자에게 안전한 전송을 위해 메시지가 어떤 인코딩이 적용되었는지 알려준다. |
| Upgrade | 클라이언트와 서버가 통신 중 발송자가 변경하길 원하는 버전이나 프로토콜을 알려준다. |
| Via | 어떤 준개자(프락시나 게이트웨이)를 거쳐 왔는지 알려준다. |
일반 캐시 헤더
HTTP/1.1에서는 서버로부터 매번 객체를 가져오는 비효율적인 방식을 개선하기 위해 캐시 기능이 도입되었다.
캐시를 사용하여 변경되지 않는 객체에 한해 로컬 복사본을 사용하게 된다.
| 헤더 | 설명 |
|---|---|
| Cache-Control | 메시지와 함께 캐시 지시자를 전달하기 위해 사용한다. 예를 들어, 캐시 만료시간이나 검증 등을 설정한다. |
요청 헤더
요청 헤더는 요청 메시지에서만 의미를 갖는 헤더다. 요청 헤더는 무엇이 요청을 보냈는지에 대한 정보나 클라이언트의 선호에 대한 정보를 정의한다.
이를 통해 서버는 클라이언트에게 더 나은 정보를 주기 위해 활용할 수 있다.
요청 보안 헤더
HTTP는 인증요구/응답 체계를 갖고 있다. 클라이언트가 리소스 접근하기 전에 자신을 인증하게 함으로써 트랜잭션을 안전하게 만들고자 한다.
| 헤더 | 설명 |
|---|---|
| Authorization | 클라이언트가 서버에게 제공할 인증에 대한 정보를 담고 있다. |
| Cookie | 쿠키 토큰을 전달할 때 사용한다. 보안 헤더는 아니지만, 보안에 영향을 줄 수 있다. |
| Cookie2 | 요청자가 지원하는 쿠키의 버전을 알려줄 때 사용한다. |
응답 헤더
응답 헤더는 클라이언트에게 부가 정보를 제공한다. 누가 응답을 보내고 그 능력은 어떻게 되는지 알려준다.
클라이언트가 응답을 잘 다루고 더 나은 요청을 할 수 있도록 유도한다.
| 헤더 | 설명 |
|---|---|
| Age | 응답이 얼마나 오래되었는지 명시한다. |
| Public | 서버가 특정 리소스에 대해 지원하는 메서드의 목록 |
| Retry-After | 현재 리소스가 사용 불가능 상태일 경우, 언제 요청 가능한지 날짜 혹은 시각 |
| Warning | 사유 구절보다 더 자세한 경고 메시지 |
응답 보안 헤더
HTTP 인증 체계에서 응답 측에 해당하는 헤더이다.
| 헤더 | 설명 |
|---|---|
| Set-Cookie | 서버가 클라이언트 측에 쿠키 토큰을 설정하기 위해 사용한다.(보안에 간접적 영향) |
| WWW-Authenticate | 서버에서 보낸 인증요구의 목록 |
엔터티 헤더
HTTP 메시지의 엔터티 본문에 대해 설명하는 헤더다. 요청과 응답 모두 엔터티를 포함할 수 있기 때문에, 이 헤더들은 양쪽 모두 나타날 수 있다.
| 헤더 | 설명 |
|---|---|
| Allow | 엔터티에 대해 수행될 수 있는 메서드들을 나열한다. |
| Location | 클라이언트에게 엔터티가 실제 어디있는지 말해준다. 수신자에게 (아마도 새로운) 리소스 위치(URL)를 알려줄 때 사용 |
엔터티 캐싱 헤더
| 헤더 | 설명 |
|---|---|
| ETag | 리소스가 변경되었다면, 새로운 ETag가 생성된다. ETag는 지문과 같은 역할을 하면서 리소스를 식별한다. |
| Expires | 엔터티 유효시간(일시) |
| Last-Modified | 최근 변경된 일시 |
