3. HTTP 메서드
다음의 내용을 중점으로 이야기합니다.
- 메세지가 어떻게 흐르는지
- HTTP 메시지의 세 부분(시작줄, 헤더, 개체 본문)
- 요청과 응답 메세지의 차이
- 요청 메시지가 지원하는 여러 기능(메서드)들
- 응답 메시지가 반환하는 여러 상태 코드들
- 여러 HTTP 헤더들이 하는 역할
3.1 메시지의 흐름#
HTTP 메시지 : HTTP 애플리케이션 간에 주고 받은 데이터의 블록
메세지는 원 서버 방향을 인바운드로 송신합니다.#
- 인바운드 : 메세지가 서버 방향으로 흐르는 것
- 아웃바운드 : 메세지가 클라이언트 방향으로 흐는 것
다운 스트림으로 흐르는 메세지#
HTTP 메세지는 반드시 다운 스트림으로 흐릅니다.
3.2 메세지의 각 부분#
메세지는 데이터의 구조화된 블록입니다. 이는 크게 세가지로 구성됩니다.
| 이름 | 예시 |
|---|---|
| 시작줄 | HTTP/1.0 200 OK |
| 헤더 | Content-type: textplan Content-length: 19 |
| 본문 | Hi, I'm a message! |
메시지 문법#
요청 메세지는 다음의 형태를 가집니다.
응답 메세짘는 다음의 형태를 가집니다.
각 부분의 설명은 다음과 같습니다.
- 메서드
- 클라이언트 측에서 서버가 리소스에 대해 수행해주길 바라는 동작
- 'GET', 'HEAD', 'POST' 등...
- 요청 URL
- 요청 대상이 되는 리소스를 지칭하는 완전한 URL
- 버전
- HTTP 버전
- 상태 코드
- 요청 중에 무엇이 있어났는지 설명하는 세자리 수
- 사유 구절(reason-phrase)
- 사람이 이해할 수 있게 설명해주는 짧은 구조
- 헤더들
- 이름, 콜론, 선택적인 공백, 값, CRLF
- 엔티티 본문
- 임의의 데이터 블록
시작줄#
모든 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|서버 에러|
- 대표적인 상태 코드는 다음과 같습니다. |상태코드|사유 구절|의미| |200|OK|성공, 요청한 모든 데이터는 응답 본문에 들어있습니다.| |401|Unauthorized|사용자 이름과 비밀번호를 입력해야합니다.| |404|Not Found|서버는 요청한 URL에 해당하는 리소스를 찾지 못합니다.|
- 사유 구절
- 응답 시작줄의 마지막 구성요소
- 버전 번호
- HTTP/x.y 형식
- 요청과 응답 모두 기술됩니다.
헤더#
시작줄 다음에는 0개, 1개 혹은 여러개의 HTTP 헤더가 옵니다. 이는 요청과 응답 메세지에 추가 정보를 줍니다.
- 일반 헤더 : 요청과 응답 양쪽에 모두 나타날 수 있음
- 요청 헤더 : 요청에 대한 부가 정보 제공
- 응답 헤더 : 응답에 대한 부가 정보 제공
- Entity 헤더 : 본문 크기와 콘텐츠, 혹은 리소스 자체 정의
- 확장 헤더 : 명세에 정의되지 않은 새로운 헤도ㅓ
ex) Date, Content-length, Content-type, Accept
엔티티 본문#
이미지, 비디오, HTML 문서, 소프트웨어 애플리케이션 등등
버전 0.9 메세지
- HTTP 포로톸홀의 초기버전
- 상태 코드, 사유 구절, 헤더가 없습니다.
3.3 메서드#
- 모든 서버가 모든 메서드를 구현하지 않습니다.
- 메서드는 대부분 제한적으로 사용됩니다.
안전한 메서드(Safe Method)#
- HTTP는 안전한 메서드라 불리는 메서드의 집합을 정의합니다.
- GET와 HEAD는 서버에 어떤 작용도 없기 때문에 안전한 메서드입니다.
GET#
- 가장 흔히 쓰이는 메서드
- 서버에게 리소스를 달라고 요청하기 위해 사용됩니다.
HEAD#
- GET처럼 행동하지만, 서버는 응답으로 헤더만을 돌려줍니다.
- 엔티티 본문은 결코 반환되지 않습니다.
- 리소스를 실제로 가져올 필요 없이 헤더만을 조사할 수 있도록 해줍니다.
다음의 장점이 있습니다.
- 리소스를 가져오지 않고도 그에 대해 무엇인가를 알아낼 수 있습니다.
- 응답의 상태 코드를 통해, 개체가 존재하는지 확인할 수 있습니다.
- 헤더를 확인하여 리소스가 변경되었는지 검사해야합니다.
PUT#
- 서버에 문서를 작성합니다.
- 서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 이미 URL이 존재한다면 본문을 사용해서 교체하는 것입니다.
- 콘텐츠 변경이 들어가기 때문에 많은 웹 서버가 PUT을 수행하기전에 인증정보가 필요합니다.
POST#
- 서버에 입력 데이터를 전송하기 위해 설계되었습니다.
TRACE#
- 클라이언트가 요청을 했을 때는 방화벽, 프락시, 게이트웨이 등의 애플리케이션을 통과하며, TRACE 메서드는 클라이언트에게 자신의 요청이 서버에 도달할 때 어떻게 보이게 되는지 알려줍니다.
- TRACE 요청은 목적지 서버에서 루프백 진단을 시작합니다.
- 일반적으로 진단을 위해 사용됩니다.
- 엔티티 본문을 보낼 수 없습니다.
OPTIONS#
- 웹 서버에게 여러 가지 종류의 지원 범위에 대해 물어봅니다.
- 여러 리소스에 대해 실제로 접근하지 않고도 어떻게 접근하는 것이 최선인지 확인할 수 있는 수단을 제공합니다.
DELETE#
- URL로 지정한 리소스를 삭제 요청합니다.
확장 메서드#
- HTTP는 필요에 따라 확장해도 문제가 없도록 설계합니다.
- 확장 메서드는 HTTP/1/1 명세에 정의되지 않은 메서드입니다.
다음의 메서드가 예시로 있습니다.
| 메서드 | 설명 |
|---|---|
LOCK | 사용자가 리소스를 잠글 수 있게 합니다. 즉, 다른 사용자가 같은 문서를 편집하지 못하도록 문서를 잠글 수 있습니다. |
MKCOL | 사용자가 문서를 생성할 수 있도록 해줍니다. |
COPY | 서버에 있는 리소스를 복사합니다. |
MOVE | 서버에 있는 리소스를 옮깁니다. |
3.4 상태 코드#
일반적으로 상태 코드는 다섯가지로 나뉩니다.
100-199: 정보성 상태 코드#
| 상태 코드 | 사유 구절 | 의미 |
|---|---|---|
| 100 | Continue | 요청의 시작 일부가 받아들어짐. 나머지 요청을 이어서 보내야함을 의미합니다. |
| 101 | Switching Protocols | 클라이언트가 Upgrade 헤더에 나열한 것 중 하나로 서버가 프로토콜을 바꾸었음을 의미합니다. |
200-299: 성공 상태 코드#
| 상태 코드 | 사유 구절 | 의미 |
|---|---|---|
| 200 | OK | 요청 정상, 엔티티 본문은 요청된 리소스를 포함합니다. |
| 201 | Created | 서버 개체를 생성하는 요청을 위한 것, 서버는 상태 코드를 보내기에 앞서 반드시 객체를 생성해야합니다. |
| 202 | Accepted | 요청은 받아졌으나, 서버는 어떤 동작을 수행하지 않았습니다. |
| 203 | Non-Authoritative Information | 리소스에 대한 검증이 못한 경우에 답변이 옵니다. |
| 204 | No Content | 엔티티 본문을 포함하지 않습니다. |
| 205 | Reset Content | HTML 폼에 채워진 모든 값을 비웁니다. |
| 206 | Partial Content | 부분 혹은 범위 요청이 성공했습니다. |
300-399: 리다이렉션 상태 코드#
| 상태 코드 | 사유 구절 | 의미 |
|---|---|---|
| 300 | Multiple Choices | 클라이언트가 동시에 여러 리소스를 가리키는 URL을 요청한 경우, 리소스의 목록과 함께 반환합니다. |
| 301 | Moved Permanently | 요청한 URL이 옮겨졌을 때 사용합니다. |
| 302 | Found | 301 상태코드와 같으나 클라이언트는 Location 헤더로 주어진 URL을 리소스를 임시로 가리키기 위한 목적으로 사용합니다. |
| 303 | See Other | 클라이언트에게 리소스를 다른 URL에서 가져와야한다고 말해줄때 쓰입니다. |
| 304 | Not Modified | 클라이언트는 헤더를 이용해 조건부 요청을 만들 수 있습니다. |
| 305 | Use Proxy | 리소스가 반드시 프락시를 통해서 접근되어야 함을 나타내기 위해 사용합니다. |
| 306 | (사용 안함) | 현재는 안씁니다. |
| 307 | Temporary Redirect | 301 상태와 비슷하지만 클라이언트는 location 헤더로 주어진 URL을 리소스를 임시로 가리키기 위한 목적으로 사용됩니다. |
400-499: 클라이언트 에러 상태 코드#
| 상태 코드 | 사유 구절 | 의미 |
|---|---|---|
| 400 | Bad Request | 클라이언트가 잘못된 요청을 보낸 경우 |
| 401 | Unauthorized | 리소스를 얻기 전에 클라이언트에게 인증을 요구하는 것 |
| 402 | Payment Required | 현재는 사용되지 않습니다. |
| 403 | Forbidden | 요청이 서버에 의해 거부된 경우 |
| 404 | Not Found | 서버가 요청한 URL을 찾을 수 없음을 알려주기 위해 사용됩니다. |
| 405 | Method Not Allowed | 지원하지 않는 메서드로 요청받았을 때 사용됩니다. |
| 406 | Not Acceptable | 클라이언트는 자신이 어떤 종류의 엔티티를 받아들이고자 하는지에 대해 매개변수로 명시합니다. |
| 407 | Proxy Authentication Required | 401과 비슷하나 리소스에 대해 인증을 요구하는 프락시 서버를 위해 사용됩니다. |
| 408 | Request Timeout | 클라이언트 요청을 완수하기 위해 시간이 너무 많이 걸리는 경우 사용됩니다. |
| 409 | Conflict | 요청이 리소스에 대해 일으킬 수 잇는 몇몇 충돌을 지정하기 위해 사용됩니다. |
| 410 | Gone | 404와 비슷하나, 서버가 한때 리소스를 가지고 있었다는 의미입니다. |
| 411 | Length Required | 요청 메세지에 Content-Length 헤더가 필요하다는 것을 요구합니다. |
| 412 | Precondition Failed | 클라이언트가 조건부 요청을 했을 때 그중 하나가 실패햇을 때 사용합니다. |
| 413 | Request Entity Too Large | 서버가 처리할 수 없는 한계를 넘은 크기의 요청인 경우입니다. |
| 414 | Request URI Too Long | 서버가 처리할 수 없는 한계를 넘은 길이를 요청한 경우입니다. |
| 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 | 현재는 서버가 요청을 처리해 줄 수 없지만 나중에는 가능함을 의미합니다. |
| 504 | Gateway Timeout | 408에러와 비슷하지만 다른 서버에게 요청을 보내고 응답을 기다리다 타임아웃이 발생한 게이트웨이나 프락시에서 온 응답입니다. |
| 505 | HTTP Version Not Supported | 서버가 지원할 수 없거나 지원하지 않으려고 하는 버전의 프로토콜로 된 요청을 받았을 때 사용됩니다. |
3.5 헤더#
헤더와 메서드는 클라이언트와 서버가 무엇을 하는지 결정하기 위해서 함께 사용됩니다.
일반 헤더(General Headers)#
- 클라이언트와 서버 양쪽 모두에서 사용됩니다.
- 메시지에 대한 아주 기본적인 정보를 제공합니다.
- 다양한 목적을 위해 사용됩니다.
- ex)
Date: Tue, 3 Oct 1974 02:16:00 GMT
다음과 같은 종류가 있습니다.
- Connection, Date, MIME-Version, Trailer chunked transfer, Transfer-Encoding, Upgrade, Via
캐시 헤더
원 서버로부터 객체를 가져오는 대신 로컬 복사본으로 캐시할 수 있도록 해주는 헤더입니다.
- Cache-Control이나 Pragma 등이 있습니다.
요청 헤더(Request Headers)#
- 요청 메세지를 위한 헤더입니다.
- 서버에게 클라이언트가 받고자 하는 데이터의 타입이 무엇인지 물어봅니다.
- ex)
Accept: */*
다음과 같은 종류가 있습니다.
- Client-IP, From, Host, Referer, UA-Color, UA-CPU, UA_Disp, UA-OS, UA-Pixels, User-Agent
Accept 관련 헤더
- Accept, Accept-Charset, Accept-Encoding, Accept-Language, TE
조건부 요청 헤더
- Expect, If-Match, If-Modified-Since, If-Range, If-Unmodified-Since, Range
요청 보안 헤더
- Authorization, Cookie, Cookie2
프락시 요청 헤더
- Max-Forwards, Proxy-Authorization, Proxy-Connection
응답 헤더(Response Headers)#
- 클라이언트에게 정보를 제공하기 위한 자신만의 헤더를 갖고 있습니다.
- 클라이언트에게 부가적인 정보를 제공합니다.
- ex)
Server: Tiki-Hut/1.01
다음과 같은 종류가 있습니다.
- Age, Public, Retry-After, Server, Title, Warning
협상 헤더
- Accept-Ranges, Vary
응답 보안 헤더
- Proxy-Authenticate, Set-Cookie, Set-Cookie2, WWW-Authenticate
엔티티 헤더(Entity Headers)#
- 엔티티 본문에 대한 헤더입니다.
- 엔티티 헤더를 통해서 본문에 들어있는 데이터의 타입을 말할 수도 있습니다.
- 광범위한 내용을 제공합니다.
- ex)
Content-Type: text/html; charset=iso-latin-1
다음과 같은 예시가 있습니다.
- Allow, Location
콘텐츠 헤더
- Content-Base, Content-Encoding, Content-Language, Content-Length, Content-Location, Content-MD5, Content-Range, Content-Type
엔티티 캐싱 헤더
- ETag, Expires, Last-Modified
확장 헤더(Extension Headers)#
- 비표준 헤더입니다.
- 모르는 헤더 정보라도 책임을 지고 넘겨야합니다.
추가 정보#
좀 더 자세한 정보는 다음에서 얻을 수 있습니다.