1. HTTP

목차

1. HTTP request / response 

2. HTTP Method

3. HTTP 응답코드

 

 

 

HTTP란?

HTTP는 클라이언트-서버 프로토콜입니다.

HTTP 프로토콜로 클라이언트와 서버가 데이터를 주고받기 위해서는 아래와 같이 요청(Request)을 보내고 응답(Response)을 받습니다.

 

클라이언트란 요청을 보내는 쪽을 의미하며 일반적으로 웹 관점에서는 브라우저를 의미하고 서버란 요청을 받는 쪽을 의미하며 일반적으로 데이터를 보내주는 원격지의 컴퓨터를 의미합니다.

 

클라이언트에 의해 전송되는 메시지를 요청(requests)이라 하고, 요청에 대해 서버에서 응답으로 전송하는 메시지를 응답(responses)이라고 한다.

 

특징으로는

[1]. ASCII로 인코딩된 텍스트 정보이며 여러 줄로 되어 있다.

[2]. 단순한 메시지 구조를 이루고 있고

[3]. 확장성이 좋다는 특징이 있다.

 

 

1. HTTP request / response

HTTP Request

 - HTTP Request Message는 공백(blank line)을 제외하고 3가지 부분으로 나누어집니다.

 

1. start line

HTTP Request Message의 시작 라인으로 3가지 부분으로 구성됩니다.

     GET         /test.html       HTTP/1.1
[HTTP Method] [Request target]  [HTTP version]

 

[1]. HTTP method

HTTP method는 요청의 의도를 담고 있는 GET, POST, PUT, DELETE 등이 있습니다. 
GET은 존재하는 자원에 대한 요청, POST는 새로운 자원을 생성, PUT은 존재하는 자원에 대한 변경,
DELETE는 존재하는 자원에 대한 삭제와 같은 기능을 가지고 있습니다.

 

[2]. Request target

HTTP Request가 전송되는 목표 주소입니다.

 

[3]. HTTP version

version에 따라 Request 메시지 구조나 데이터가 다를 수 있어서 version을 명시합니다.

 

 

2. Headers

해당 request에 대한 추가 정보(addtional information)를 담고 있는 부분입니다.

 

 - request 메세지 body의 총 길이 (Content-Length) 등 Key:Value 형태로 구성

 - headers도 크게 3가지 부분으로 나뉘어집니다.(general headers, request headers, entity headers)

Host: google.com
Accept: text/html
Accept-Encoding: gzip, deflate
Connection: keep-alive
...

 

[1]. Request 헤더

 - 요청의 내용을 좀 더 구체화하고, context를 제공한다. 조건부로 제한하여 요청 내용을 수정하기도 한다.

1. Host
 - 서버의 도메인 네임, Host 헤더는 반드시 하나가 존재해야 한다.
EX) host: goddaehee.tistory.com


2. User-Agent
가장 흔하게 보고 사용하는 헤더입니다.
현재 사용자가 어떤 클라이언트(운영체제, 앱, 브라우저 등)를 통해 요청을 보냈는지 알 수 있다.
EX) User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Window로 크롬 브라우저를 통해 접속 하였다. 다만 헤더는 변경 할 수 있기 때문에 무조건 신뢰할 수는 없다.
그래도 매우 유용한 헤더이며 이를 활용하여 접속자 및 사용기기 통계를 내기도 한다.


3. Accept
클라이언트가 허용할 수 있는 파일 형식(MIME TYPE)
EX)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate
Accept-Language: ko-KR,ko;q=0.9,en-US;q=0.8,en;q=0.7


4. Cookie
웹서버가 클라이언트에 쿠키를 저장해 놓았다면 해당 쿠키의 정보를 이름-값 쌍으로 웹서버에 전송한다.


5. Origin
Origin은 url 주소상에서 프로토콜, Domain 이름, 포트까지 포함한 개념입니다.Same Origin이란 같은 Origin을 뜻하고 Cross Origin 이란 서로 다른 Origin을 뜻하는 말이다. 여기에 붙은 Resrouce Sharing 의 단어까지 포함하면 
CORS는 서로 다른 Origin간의 리소스 교환을 의미합니다.
EX) Origin : http://goddaehee.tistory.com
EX) Referer: http://goddaehee.tistory.com


6. If-Modified-Since
페이지가 수정되었으면 최신 버전 페이지 요청을 위한 필드,만일 요청한 파일이 이 필드에 지정된 시간 이후로 변경되지 않았다면, 서버로부터 데이터를 전송받지 않는다.


7. Authorization
Authorization 헤더는 인증 토큰을 서버로 보낼 때 사용하는 헤더.
API 요청같은 것을 할 때 토큰이 없으면 거절당하기 때문에 이 때, Authorization을 사용한다.
JWT(Json Web Token) 을 사용한 인증에서 주로 사용 한다.
EX) Authorization: Bearer xxx.xxx.xxx

 

[2]. General 헤더

 - 메시지 전체에 적용되는 헤더입니다.

1. Date
HTTP 메시지가 만들어진 시각입니다. 자동으로 만들어집니다.
EX) Date: Sun, 13 Jan 2019 17:28:13 GMT


2. Connection
일반적으로 HTTP/1.1을 사용하며 Connection은 기본적으로 keep-alive로 되어있다. 별 의미 없는 헤더.
EX) Connection: keep-alive


3. Content-Length
요청과 응답 메시지의 본문 크기를 바이트 단위로 표시해준다. 메시지 크기에 따라 자동으로 만들어진다.
EX) Content-Length: 88052


4. Cache-Control
Cache-Control 헤더는 캐싱을 허용할지 허용하지 않을지를 정하기 위해 사용된다.
EX) Cache-Control: no-cache



5. Content-Type
컨텐츠의 타입(MIME)과 문자열 인코딩(utf-8 등등)을 명시할 수 있다.
EX) Content-Type: text/html; charset=utf-8 (현재 메시지 내용이 text/html 타입이고 문자열은 utf-8 문자열)
    서버로 데이터를 보낼 때는 text/html 대신 www-url-form-encoded, multipart/form-data 등이 Content-Type이 된다.


6. Content-Language
사용자의 언어. 
EX) Content-Language=ja
(http://jpn.lottedfs.com/kr/display/category/third?dispShopNo1=1300091&dispShopNo2=1300092&dispShopNo3=1300093&treDpth=3)


7. Content-Encoding
응답 컨텐츠를 br, gzip, deflate 등의 알고리즘으로 압축해서 보내면, 브라우저가 알아서 해제해서 사용한다.
이 외에도 다양한 압축 알고리즘이 존재한다.
요청이나 응답 전송 속도도 빨라지고, 데이터 소모량도 줄어들기 때문에 사용한다..
EX) Content-Encoding: gzip, deflate

 

[3]. Entity 헤더

 - 요청 본문에 적용되는 헤더이다. 요청 내에 본문이 없는 경우에는 당연히 전송되지 않습니다.

1. Content-Length
Content-Length는 바이트 단위를 가지는 Header + Body의 크기를 나타낸다.메시지 크기에 따라 자동으로 생성된다.
EX) Content-Length: <length>


2. Content-Type
Content-Type는 개체의 미디어 타입(MIME)과 문자열 인코딩(UTF-8)을 지정하기 위해 사용한다.
EX) 메시지 내용은 text/html 타입, 문자열은 utf-8 문자열이라는 의미입니다.
Content-Type: text/html; charset=utf-8
Content-Type: multipart/form-data; boundary=something


3. Content-Language
사용자들에게 언어를 설명하기 위해 사용됩니다.
사용자가 선호하는 언어에 따라 사용자를 구분할 수 있게 한다.
만약 Content-Language가 지정되지 않으면 모든 사람들에게 공개된 정보라고 간주합니다.
Content-Language는 Text 뿐만 아니라 미디어 타입에도 적용됩니다.
EX)
Content-Language: de-DE
Content-Language: en-US
Content-Language: de-DE, en-CA

HTML 문서에도 다음과 같이 사용할 수 있지만 사용하지 않는것을 MDN에서 권고합니다.
EX)
<!-- /!\ This is bad practice --> <meta http-equiv="content-language" content="de">


4. Content-Encoding
Content-Encoding 은 미디어 타입을 압축하기 위해서 사용된다.이 헤더가 존재한다면 그 값은어떤 방식으로 인코딩 되는지 알 수 있다.우리가 gzip등의 알고리즘을 통해 encoding 해서 보낸다면 브라우저가 알아서 해제해서 사용한다.
EX)
Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
Content-Encoding: identity
Content-Encoding: br
// Content-Encoding: gzip

 

 

3. Body

HTTP 요청 본문은 요청에서 보낼 데이터이며, 일반적으로 ‘GET’, ‘HEAD’, ‘DELETE’, ‘OPTIONS’에는 요청 본문이 없습니다.

(리소스를 조회하거나 삭제하는 경우에만 사용합니다.)

요청 본문은 POST, PUT 등으로 리소스에 데이터를 전송하는 경우에 이용합니다.

 

EX) POST 요청

POST /test HTTP/1.1

Accept: application/json
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 83
Content-Type: application/json
Host: google.com
User-Agent: HTTPie/0.9.3

{
    "test_id": "tmp_1234567",
    "order_id": "8237352"
}

 

 

HTTP Response

 - HTTP Response Message는 request와 동일하게 공백(blank line)을 제외하고 3가지 부분으로 나누어진다.

 

1. status line

HTTP Response의 상태를 간략하게 나타내주는 부분입니다.

HTTP Response의 status line은 3가지 부분으로 구성됩니다.

   HTTP/1.1         200           OK
[HTTP version] [Status Code] [Status Text]

 

[1]. HTTP Version

응답온 메세지의 HTTP 버젼 정보입니다.

 

[2]. Status Code

응답 코드입니다.

 

[3]. HTTP version

응답 상태입니다.

 

 

2. Headers

Response의 headers와 동일하지만.response에서만 사용되는 header 값들이 있습니다.

EX) User-Agent 대신에 Server 헤더가 사용된다.

 

 

[1]. Response 헤더

 - 상태 줄에 미처 들어가지 못했던 서버에 대한 추가 정보를 제공합니다.

1. Access-Control-Allow-Origin
요청 Host와 응답 Host가 다르면 CORS 에러가 발생하는데 서버에서 응답 메시지입니다.
Access-Control-Allow-Origin 헤더에 프론트 주소를 적어주면 에러가 발생하지 않습니다.
EX) Access-Control-Allow-Origin: goddaehee.tistory.com

관련 헤더
 - Access-Control-Request-Method : 실제로 보내려는 메서드
 - Access-Control-Request-Headers : 실제로 보내려는 헤더
 - Access-Control-Allow-Methods : 서버가 허용하는 메서드
 - Access-Control-Allow-Headers : 서버가 허용하는 헤더

2. Set-Cookie
서버 측에서 클라이언트에게 세션 쿠키 정보를 설정할 때 사용하는 항목 (RFC 2965에서 규정)
자바스크립트에서 쿠키에 접근할 수 없으며, XSS 요청을 막으려면 활성화해두는 것이 좋습니다.
쿠키는 XSS 공격과 CSRF 공격 등에 취약하기 때문에 HttpOnly 옵션을 켜두고,
쿠키를 사용하는 요청은 서버 단에서 검증하는 로직을 마련해두는 것이 좋다.
EX) Set-Cookie: zerocho=babo; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly

 

[2]. General 헤더

 - 메시지 전체에 적용되는 헤더입니다.

1. Server: 웹 서버 (소프트웨어) 정보

2. Via: 요청헤더와 응답헤더에 포워드 프록시와 리버스 프록시에 의해서 추가된다.
포워드 메시지를 추적하거나, 요청 루프 방지, 요청과 응답 체인에 따라 송신자의 프로토콜 정보를 식별함.

 

[3]. Entity 헤더

 - 요청 본문에 적용되는 헤더이다. 요청 내에 본문이 없는 경우에는 당연히 전송되지 않는다.

1. Content-Encoding
응답 콘텐츠 압축하는 방식입니다.
br, gzip, deflate 등의 알고리즘으로 압축해서 보내면 브라우저가 알아서 해제해서 사용합니다.
요청이나 응답 전송 속도도 빨라지고, 데이터 소모량도 줄어들기 때문에 사용합니다.

2. Content-Type
콘텐츠의 미디어 타입(MIME Type). 반환된 콘텐츠 타입이 실제로 무엇인지 클라이언트에게 알려줍니다.

3. Date: 현재 날짜

4. Last-Modified: 요청한 파일의 최종 수정일

 

 

3. Body

본문은 요청의 마지막 부분에 들어갑니다.

Request와 마찬가지로 모든 response가 body가 들어가지는 않습니다.

데이터를 전송할 필요가 없을경우 body가 비어있게 됩니다.

 

 

2. HTTP Method

HTTP 메서드의 종류

[1]. GET

리소스를 조회할 때 사용.
쿼리 파라미터를 통해 서버에 데이터 전달.
메시지 바디를 통해서도 데이터를 전달할 수 있지만, 지원하지 않는 곳이 많음.

EX)
GET [request-uri]?query_string HTTP/1.1
Host:[Hostname] 혹은 [IP]

 

[2]. POST

메시지 바디를 통해 서버로 요청 데이터를 전달한다.

서버는 메시지 바디를 통해 들어온 데이터를 처리하는 모든 기능을 수행한다.
주로 전달된 데이터를 신규 리소스 등록, 요청 데이터 처리, 다른 메서드로 처리하기 애매한 경우에 사용한다.
리소스 URI에 POST 요청이 오면 요청 데이터를 어떻게 처리해야 되는지 정해진 것이없기 때문에,
리소스마다 어떻게 처리할지 따로 정해야 한다.
POST의 결과로 새로운 리소스가 생성되지 않을 수도 있다.
신규 리소스 등록 시 클라이언트는 등록될 리소스의 URI를 모르고,서버가 새로 등록된 리소스 URI를 생성해준다.

컬렉션 : 서버가 관리하는 리소스 디렉토리, 서버가 리소스 URI를 생성하고 관리한다.

참고 : 신규로 리소스가 생성되면 보통 HTTP 상태 코드 201 created와 location 헤더에 리소스가 생성된 경로를 보낸다. 그냥 200으로 보내도 된다.

EX)  
POST [request-uri] HTTP/1.1
Host:[Hostname] 혹은 [IP]
Content-Lenght:[Length in Bytes]
Content-Type:[Content Type]
[데이터] 

 

[3]. PUT

리소스가 있으면 대체하고, 없으면 생성한다.(덮어쓰기)
신규 리소스 등록 시 클라이언트가 직접 리소스의 URI를 지정한다.
스토어 : 클라이언트가 관리하는 리소스 저장소, 클라이언트가 리소스의 URI를 알고 관리한다.

EX)  
PUT [request-uri] HTTP/1.1
Host:[Hostname] 혹은 [IP]
Content-Lenght:[Length in Bytes]
Content-Type:[Content Type]
[데이터] 

 

[4]. PATCH

리소스를 부분적으로 변경한다.
간혹 PATCH를 지원하지 않는 서버가 있을 수 있는데, 이 경우 POST를 사용하면 된다.
해당자원의 일부를 교체하는 의미로 사용합니다.

EX)
PATCH [request-uri] HTTP/1.1
Host:[Hostname] 혹은 [IP]
Content-Lenght:[Length in Bytes]
Content-Type:[Content Type]
[데이터] 

 

[5]. DELETE

요청된 자원을 삭제할 것을 요청합니다.  
안전성 문제로 대부분의 서버에서 비활성화 합니다.

EX) 
DELETE [request-uri] HTTP/1.1
Host:[Hostname] 혹은 [IP]

 

[6]. 기타

HEAD, OPTIONS, CONNECT, TRACE가 있다.
HEAD : GET과 동일하지만,  응답코드와 헤더만 반환.(본문(Body)을 포함하지 않는다)
             웹서버 정보확인, 헬스체크, 버젼확인, 최종 수정일자 확인등의 용도로 사용됩니다.
OPTIONS : 대상 리소스에 대한 통신 가능 메서드를 설명(주로 CORS에서 사용)
CONNECT : 대상 자원으로 식별되는 서버에 대한 터널을 설정.
TRACE : 대상 리소스에 대한 경로를 따라 메시지 루프백 테스트를 수행.

 

 

3. HTTP 응답코드

클라이언트가 보낸 HTTP 요청에 대한 서버의 응답 코드 입니다.

상태 코드는 3자리 숫자로 만들어져 있으며, 첫번째 자리는 1에서 5까지 제공됩니다.

첫번째 자리가 4와 5인 경우는 정상적인 상황이 아니기 때문에 사이트 관리자가 즉시 알아야 하는 정보입니다.

 

1xx(정보) : 요청을 받았으며 프로세스를 계속 진행합니다.
2xx(성공) : 요청을 성공적으로 받았으며 인식했고 수용하였습니다.
3xx(리다이렉션) : 요청 완료를 위해 추가 작업 조치가 필요합니다.
4xx(클라이언트 오류) : 요청의 문법이 잘못되었거나 요청을 처리할 수 없습니다.
5xx(서버 오류) : 서버가 명백히 유효한 요청에 대한 충족을 실패했습니다.

 

1XX : Information responses

상태 코드가 '1'로 시작하는 경우는 서버가 요청을 받았으며, 서버에 연결된 클라이언트는 작업을 계속 진행하라는 의미입니다. 해당 코드는 HTTP 1.0에서 지원되지 않습니다.

100 Continue 진행 중임을 의미하는 응답코드입니다.
현재까지의 진행상태에 문제가 없으며, 클라이언트가 계속해서 요청을 하거나 이미 요청을 완료한 경우에는 무시해도 되는 것을 알려줍니다.

101 Switching Protocol
101은 클라이언트에 의해 보낸 업그레이드 요청 헤더에 대한 응답으로 보내집니다.
이 응답 코드는 클라이언트가 보낸 Upgrade 요청 헤더에 대한 응답에 들어가며, 서버에서 프로토콜을 변경할 것임을 알려줍니다. 해당 코드는 Websocket 프로토콜 전환 시에 사용됩니다.

102 Processing(WebDAV)
이 응답 코드는 서버가 요청을 수신하였으며 이를 처리하고 있지만, 아직 제대로 된 응답을 알려줄 수 없음을 알려줍니다.

103 (Early Hints)
Link해더와 함께 사용되며 주로 서버가 응답을 준비하는 동안 사용자가 사전로딩(PreLoading)을 할수 있도록 하는 응답코드

 

2XX : Successful responses

클라이언트가 요청한 동작을 수신하여 이해했고 승낙했으며 성공적으로 처리했음을 알려줍니다.

200 OK
요청이 성공적으로 되었습니다. 정보는 요청에 따른 응답으로 반환됩니다.

201 Created
요청이 성공적이었으며 그 결과로 새로운 리소스가 생성되었습니다. 이 응답은 일반적으로 POST 요청 또는 일부 PUT 요청 이후에 따라옵니다.

202 Accepted
요청을 수신하였지만, 그에 응하여 행동할 수 없습니다. 이 응답은 요청 처리에 대한 결과를 이후에 HTTP로 비동기 응답을 보내는 것에 대해서 명확하게 명시하지 않습니다. 이것은 다른 프로세스에서 처리 또는 서버가 요청을 다루고 있거나 배치 프로세스를 하고 있는 경우를 위해 만들어졌습니다.

203 Non-Authoritative Information
이응답 코드는 돌려받은 메타 정보 세트가 오리진 서버의 것과 일치하지 않지만 로컬이나 서드 파티 복사본에서 모아졌음을 의미합니다. 이러한 조건에서는 이 응답이 아니라 200 OK 응답을 반드시 우선됩니다.

204 No Content
요청에 대해서 보내줄 수 있는 콘텐츠가 없지만, 헤더는 의미있을 수 있습니다. 사용자-에이전트는 리소스가 캐시된 헤더를 새로운 것으로 업데이트 할 수 있습니다.

205 Reset Content
이 응답 코드는 요청을 완수한 이후에 사용자 에이전트에게 이 요청을 보낸 문서 뷰를 리셋하라고 알려줍니다.

206 Partial Content
이 응답 코드는 클라이언트에서 복수의 스트림을 분할 다운로드를 하고자 범위 헤더를 전송했기 때문에 사용됩니다. 클라이언트가 이어받기를 시도하면 웹서버가 이에 대한 응답코드로 '206 Partial Content'와 함께 Range 헤더에 명시된 데이터의 부분(byte)부터 전송을 시작합니다.

207 Multi-Status
멀티-상태 응답은 여러 리소스가 여러 상태 코드인 상황이 적절한 경우에 해당되는 정보를 전달합니다. 해당 코드는 WebDAV(Web Distributed Authoring and Vesioning)에 사용됩니다.

208 Already Reported Prostat(property와 status의 합성어)
응답 속성으로 동일 컬렉션으로 바인드된 복수의 내부 멤버를 반복적으로 열거하는 것을 피하기 위해 사용됩니다. 해당 코드는 WebDAV(Web Distributed Authoring and Vesioning)에 사용됩니다.

226 IM Used ( HTTP Delta encoding )
서버가 GET 요청에 대한 리소스의 의무를 다 했고, 그리고 응답이 하나 또는 그 이상의 인스턴스 조작이 현재 인스턴스에 적용이 되었음을 알려줍니다.

 

3XX : Redirection messages

이 요청을 완료하기 위해서는 리다이렉션이 이루어져야 한다는 의미입니다. 짧은 주소(단축 URL) 서비스의 경우 접속 시 301이나 302 코드를 보내고, 헤더의 location에 리다이렉션할 실제 URL을 적어 보냅니다.

300 Multiple Choice
요청에 대해서 하나 이상의 응답이 가능합니다.
사용자 에언트 또는 사용자는 그중에 하나를 반드시 선택해야 합니다.
응답 중 하나를 선택하는 방법에 대한 표준화 된 방법은 존재하지 않습니다.

301 Moved Permanently
이 응답 코드는 요청한 리소스의 URI가 변경되었음을 의미합니다.
새로운 URI가 응답에서 아마도 주어질 수 있습니다.

302 Found
이 응답 코드는 요청한 리소스의 URI가 일시적으로 변경되었음을 의미합니다.
새롭게 변경된 URI는 나중에 만들어질 수 있습니다.
그러므로, 클라이언트는 향후의 요청도 반드시 동일한 URI로 해야합니다.

303 See Other
클라이언트가 요청한 리소스를 다른 URI에서 GET 요청을 통해 얻어야 할 때,
서버가 클라이언트로 직접 보내는 응답입니다.

304 Not Modified 이것은 캐시를 목적으로 사용됩니다.
이것은 클라이언트에게 응답이 수정되지 않았음을 알려주며,
그러므로 클라이언트는 계속해서 응답의 캐시된 버전을 사용할 수 있습니다.

305 Use Proxy
이전 버전의 HTTP 기술 사양에서 정의되었으며,
요청한 응답은 반드시 프록시를 통해서 접속해야 하는 것을 알려줍니다.
이것은 프록시의 in-band설정에 대한 보안상의 걱정으로 인하여 사라져가고 있습니다.

306 Unused
이 응답 코드는 더이상 사용되지 않으며, 현재는 추후 사용을 위해 예약되어 있습니다.
이것은 HTTP 1.1 기술사양 이전 버전에서 사용되었습니다.

307 Temporary Redirect
클라이언트가 요청한 리소스가 다른 URI에 있으며,이전 요청과 동일한 메소드를 사용하여 요청해야 할 때, 서버가 클라이언트에 이 응답을 직접 보냅니다.
이것은 302 Found HTTP 응답 코드와 동일한 의미를 가지고 있으며, 사용자 에이전트가 반드시 사용된 HTTP 메소드를 변경하지 말아야 하는 점만 다릅니다.
만약 첫 요청에 POST가 사용되었다면, 두번째 요청도 반드시 POST를 사용해야 합니다.

308 Permanent Redirect
이것은 리소스가 이제 HTTP 응답 헤더의 Location:에 명시된 영구히 다른 URI에 위치하고 있음을 의미합니다.
이것은 301 Moved Permanently HTTP 응답 코드와 동일한 의미를 가지고 있으며, 사용자 에이전트가 반드시 HTTP 메소드를 변경하지 말아야 하는 점만 다릅니다.
만약 첫 요청에 POST가 사용되었다면, 두번째 요청도 반드시 POST를 사용해야 합니다.

 

4XX : Client error responses

클라이언트가 서버에게 보낸 요청이 잘못된 경우를 의미합니다.

400 Bad Request
이 응답은 잘못된 문법으로 인하여 서버가 요청하여 이해할 수 없음을 의미합니다.

401 Unauthorized
비록 HTTP 표준에서는 '미승인(unauthorized)'를 명확히 하고 있지만, 의미상 이 응답은 '비인증(unauthenticated)'를 의미합니다. 클라이언트는 요청한 응답을 받기 위해서는 반드시 스스로를 인증해야 합니다.

402 Payment Required
이 응답 코드는 나중에 사용될 것을 대비해 예약되었습니다.
첫 목표로는 디지털 결제 시스템에 사용하기 위하여 만들어졌지만 지금 사용되고 있지는 않습니다.

403 Forbidden
클라이언트는 콘텐츠에 접근할 권리를 가지고 있지 않습니다. 예를 들어, 그들은 미승인이어서 서버는 거절을 위한 적절한 응답을 보냅니다. 401과 다른 점은 서버가 클라이언트가 누구인지 알고 있습니다.

404 Not Found
서버는 요청받은 리소스를 찾을 수 없습니다. 브라우저에서는 알려지지 않은 URL을 의미합니다.
이것은 API에서 종점은 적절하지만 리소스 자체는 존재하지 않음을 의미할 수 있습니다.
서버들은 인증받지 않은 클라이언트로부터 리소스를 숨기기 위하여 이 응답을 403 대신에 전송할 수도 있습니다.
이 응답 코드는 웹에서 반복적으로 발생하기 때문에 가장 유명할지도 모릅니다.

405 Method Not Allowed
요청한 메소드는 서버에서 알고 있지만, 제거되었고 사용할 수 없습니다.
예를 들어, 어떤 API에서 리소스를 삭제하는 것을 금지할 수 있습니다.
필수적인 메소드인 GET과 HEAD는 제거될 수 없으며, 이 에러 코드를 리턴할 수 없습니다.

406 Not Acceptable
이 응답은 서버가 서버 주도 콘텐츠 협상을 수행한 후, 사용자 에이전트에서 정해준 규격에 따른 어떠한 콘텐츠도 찾지 않았을 때, 웹서버가 보냅니다.

407 Proxy Authentication Required
이것은 401과 비슷하지만 프록시에 의해 완료된 인증이 필요합니다.

408 Request Timeout
이 응답은 요청을 한 지 시간이 오래된 연결에 일부 서버가 전송하며, 어떤 때에는 이전에 클라이언트로부터 어떠한 요청이 없었다고 하더라도 보내지기도 합니다. 이것은 서버가 사용되지 않는 연결을 끊고 싶어하는 것을 의미합니다. 이 응답은 특정 몇몇 브라우저에서 빈번하게 보이는데 Chrome, Firefox 27+, 또는 IE 9와 같은 웹서핑 속도를 올리기 위해 HTTP 사전 연결 메카니즘을 사용하는 브라우저들이 해당됩니다. 또한 일부 서버는 이 메시지를 보내지 않고 연결을 끊어버리기도 합니다.

409 Conflict
이 응답은 요청이 현재 서버의 상태와 충돌될 때 보냅니다.

410 Gone
이 응답은 요청한 콘텐츠가 서버에서 영구적으로 삭제되었으며, 전달해 줄 수 있는 주소 역시 존재하지 않을 때 보냅니다. 클라이언트가 그들의 캐시와 리소스에 대한 링크를 지우기를 기대합니다.
HTTP 기술 사양은 이 상태 코드가 '일시적인, 홍보용 서비스'에 사용되기를 기대합니다.
API는 알려진 리소스가 이 상태 코드와 함께 삭제되었다고 강요해서는 안된다.

411 Length Required
서버에서 필요로 하는 Content-Length 헤더 필드가 정의되지 않은 요청이 들어왔기 때문에 서버가 요청을 거절합니다.

412 Precondition Failed 클라이언트의 헤더에 있는 전제조건은 서버의 전제조건에 적절하지 않습니다.

413 Payload Too Large
요청 엔티티는 서버에서 정의한 한계보다 큽니다. 서버는 연결을 끊거나 혹은 Retry-After 헤더 필드로 돌려보낼 것이다.

414 URI Too Long
클라이언트가 요청한 URI는 서버에서 처리하지 않기로 한 길이보다 깁니다.

415 Unsupported Media Type
요청한 미디어 포맷은 서버에서 지원하지 않습니다. 서버는 해당 요청을 거절할 것입니다.

416 Requested Range Not Satisfiable Range
헤더 필드에 요청한 지정 범위를 만족시킬 수 없습니다. 범위가 타겟 URI 데이터의 크기를 벗어났을 가능성이 있습니다.

417 Expectation Failed
이 응답 코드는 Expect 요청 헤더 필드로 요청한 예상이 서버에서는 적당하지 않음을 알려줍니다.

418 I'm a teapot
서버는 커피를 찻 주전자에 끓이는 것을 거절합니다.

421 Misdirected Request
서버로 유도된 요청은 응답을 생성할 수 없습니다.
이것은 서버에서 요청 URI와 연결된 스킴과 권한을 구성하여 응답을 생성할 수 없을 때 보내집니다.

422 Unprocessable Entity (WebDAV)
요청은 잘 만들어졌지만, 문법 오류로 인하여 따를 수 없습니다.

423 Locked (WebDAV)
리소스는 접근하는 것이 잠겨있습니다.

424 Failed Dependency (WebDAV)
이전 요청이 실패하였기 때문에 지금의 요청도 실패하였습니다.

426 Upgrade Required
서버는 지금의 프로토콜을 사용하여 요청을 처리하는 것을 거절하였지만, 클라이언트가 다른 프로토콜로 업그레이드를 하면 처리를 할지도 모릅니다. 서버는 Upgrade 헤더와 필요로 하는 프로토콜을 알려주기 위해 426 응답에 보냅니다.

428 Precondition Required
오리진 서버는 요청이 조건적이어야 합니다.클라이언트가 리소스를 GET해서, 수정하고, 그리고 PUT으로 서버에 돌려놓는 동안 서드파티가 서버의 상태를 수정하여 발생하는 충돌인 '업데이트 상실'을 예방하기 위한 목적입니다.

429 Too Many Requests
사용자가 지정된 시간에 너무 많은 요청을 보냈습니다("rate limiting").

431 Request Header Fields Too Large
요청한 헤더 필드가 너무 크기 때문에 서버는 요청을 처리하지 않을 것입니다.
요청은 크기를 줄인 다음에 다시 전송해야 합니다.

451 Unavailable For Legal Reasons
사용자가 요청한 것은 정부에 의해 검열된 웹페이지와 같은 불법적인 리소스입니다.

 

 

5XX : Server error responses

올바른 요청에 대해 서버가 응답할 수 없다는 의미입니다.

500 Internal Server Error
웹 사이트 서버에 문제가 있음을 의미하지만 서버는 정확한 문제에 대해 더 구체적으로 설명할 수 없습니다.

501 Not Implemented
서버가 요청을 이행하는 데 필요한 기능을 지원하지 않음을 나타냅니다.

502 Bad Gateway
서버가 게이트웨이로부터 잘못된 응답을 수신했음을 의미합니다.
인터넷상의 서버가 다른 서버로부터 유효하지 않은 응답을 받은 경우 발생합니다.

503 Service Unavailable
서버가 요청을 처리할 준비가 되지 않았습니다.
일반적인 원인은 유지보수를 위해 작동이 중단되거나 과부하가 걸린 서버입니다.
이 응답과 함께 문제를 설명하는 사용자 친화적인 페이지가 전송되어야 한다는 점에 유의하십시오.
이 응답은 임시 조건에 사용되어야 하며, Retry-After: HTTP 헤더는 가능하면 서비스를 복구하기 전 예상 시간을 포함해야 합니다.
웹마스터는 또한 이러한 일시적인 조건 응답을 캐시하지 않아야 하므로 이 응답과 함께 전송되는 캐싱 관련 헤더에 대해서도 주의해야 합니다.

504 Gateway Timeout
웹페이지를 로드하거나 브라우저에서 다른 요청을 채우려는 동안 한 서버가 액세스하고 있는 다른 서버에서 적시에 응답을 받지 못했음을 의미합니다.
이 오류 응답은 서버가 게이트웨이 역할을 하고 있으며 적시에 응답을 받을 수 없을 경우 주어집니다.
이 오류는 대게 인터넷상의 서버 간의 네트워크 오류이거나 실제 서버의 문제입니다.
컴퓨터, 장치 또는 인터넷 연결에 문제가 아닐 수 있습니다.

505 HTTP Version Not Supported
서버에서 지원되지 않는 HTTP 버전을 클라이언트가 요청하였습니다.
대부분의 웹 브라우저는 웹 서버가 1.x 버전의 HTTP 프로토콜을 지원한다고 가정합니다.
실제로 1.0 이하의 매우 오래된 버전은 요즘 거의 사용되지 않습니다.
특히 최신 버전의 프로토콜보다 보안 및 성능이 좋지 않기 때문입니다.
따라서 웹 브라우저에서 이 오류가 표시되는 경우 웹 서버 소프트웨어에서 지원하는 HTTP 버전을 확인해 보아야 합니다.

506 Variant Also Negotiates
서버에 내부 구성 오류가 있는 경우 발생합니다.
요청을 위한 투명한 콘텐츠 협상이 순환 참조로 이어집니다.

507 Insufficient Storage
선택한 가변 리소스는 투명한 서버에 내부 구성 요류가 있는 경우 발생합니다.
콘텐츠 협상에 참여하도록 구성되므로 협상 과정에서 적절한 끝점이 아닙니다.

508 Loop Detected (WebDAV)
서버가 요청을 처리하는 동안 무한 루프를 감지한 경우 발생합니다.

510 Not Extended
서버가 요청을 이행하려면 요청에 대한 추가 확장이 필요합니다.

511 Network Authentication Required
511 상태 코드는 클라이언트가 네트워크 액세스를 얻기 위해 인증할 필요가 있음을 나타냅니다.