2019년 8월 17일

HTTP 메세지 - 상태코드

출처: http-decision-diagram

1. HTTP 응답에, 어떤 상황에 해당 상태코드가 반환되는지를 보여주는 시각화 다이어그램 자료이다.

상태코드와 사유구절

클라이언트에게 그들의 트랜잭션을 이해할 수 있는 쉬운 방법을 제공한다. => 상태코드, 사유구절
1. HTTP/1.1 기준이다.

상태코드 (HTTP/1.1 기준)

정보성 상태 코드 (100 - 199)

1. HTTP/1.1에 도입되었다.
복잡함을 감수할만한 가치가 있는지에 대한 논란이 되고 있다.

100 - Continue

요청의 시작 부분 일부가 받아들여졌으며, 클라이언트는 나머지를 계속 이어서 보내야 함을 의미한다.
이것을 보낸 후 서버는 반드시 요청을 받아 응답해야 한다.
클라가 서버에 엔터티 본문을 전송하기 전에 그 엔터티 본문을 서버가 받아들일 것인지 확인하려고 할 때, 그 확인 작업을 최적화하기 위한 의도로 도입된 것이다.

클라이언트와 100 Continue

클라이언트가 엔터티를 서버에게 보내려고 하고, 100 continue 응답을 기다리겠다면, 클라는 Expect 요청 헤더를 보낼 필요가 있다.


Expect: 100-continue

Expect

최적화를 위한 것이다.
서버가 다루거나 사용할 수 없는 큰 엔터티를 서버에게 보내지 않으려는 목적으로만 사용해야 한다.
100 Continue 값이 담긴 Expect 헤더를 보낸 클라 서버가 100 Continue 응답을 보내주기를 막연히 기다리면 안 된다. 약간의 타임아웃 후에 클라는 그냥 엔터티를 보내야 한다.
- 프론트 개발자는 예상치 못한 100 Continue 응답에도 대비해야한다..

서버와 100 Continue

서버가 100 Continue 값이 담긴 expect 헤더가 포함된 요청을 받는다면

100 Continue 응답 혹은
에러코드로 답해야한다. 417 Expectation Failed 에러

받은 엔터티에 대한 최종 응답코드는 보내줘야 한다.

클라: 서버에게 expect 헤더 보냄
서버: 음! 받을 수 있으니, 100을 보내야겠군
클라: 왜 안 오지 그냥 entity 보내자.
서버: 음? 100 아직 안보냈는데 entity가 왔네. 걍 받자
서버: 잘 받았어 ~ 응답 보내줘야 함

엔터티 읽다가 에러가 나와도, 연결을 닫아서는 안된다.
클라가 응답을 받을 수 없게 되기 때문이다. (?)
- 아직 잘 모르겠다.

프락시와 100 Continue

클라: 서버에게 expect 헤더 보냄
프락시: 서버에게 expect 헤더 고대로 보냄
1. 만약 다음 홉서버가(next-hope) HTTP/1.1 이전 버전이라는 걸 알게 되면 417 Expectation Failed를 클라에게 응답한다.

101 - switching protocols

클라이언트가 upgrade 헤더에 나열한 것 중 하나로 서버가 프로토콜을 바꾸었음을 의미한다.
웹 소켓과 함께 사용될 수 있다.

아래는 upgrade 헤더의 웹소켓으로 서버가 프로토콜을 바꿨다는 의미이다.


HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade

성공 상태 코드 (200 - 299)

200 - OK

요청은 정상이고, 엔터티 본문은 요청된 리소스를 포함하고 있다.
- GET: 리소스를 가져왔고 메시지 바디에 전송되었다.
- HEAD: 개체 헤더가 메시지 바디에 있다.
- POST: 리소스가 명시하는 행동의 결과가 메시지 바디에 전송되었다.
- TRACE: 서버가 요청받은 메시지가 메시지 바디에 포함되어있다.
- PUT 또는 DELETE의 성공 결과는 종종 200 OK가 아니라 204 No Content (또는 201 Created 리소스가 처음으로 업로드되었을 때)이다
200응답은 캐쉬될 수 있다.

201 - Created

서버 개체를 생성하라는 요청을 위한 것 (PUT)
서버는 반드시 객체를 생성하고 해당코드로 응답해야 한다.
응답에는
- location 헤더: 생성된 리소스에 대한 최대한 구체적인 참조
- 엔터티 본문: 그 리소스를 참조할 수 있는 여러 URL

202 - Accepted

요청은 받아들여졌으나, 서버는 아직 그에 대한 어떤 동작도 수행하지 않았다.
서버가 요청의 처리를 완료할 것인지에 대한 어떤 보장도 없다. 요청을 받아들이기에 적법해 보인다는 의미이다.
응답
- 엔터티 본문: 요청에 대한 상태와, 요청의 처리가 언제 완료될 것인지에 대한 추정(혹은 그에 대한 정보를 어디서 얻을 수 있는지)을 포함해야 한다.

203 - Non-Authoritative Information

엔터티 헤더에 들어있는 정보가 원래 서버가 아닌 리소스의 사본에서 왔다.(?)
프록시가 리소스의 사본을 갖고 있었지만 리소스에 대한 메타 정보(헤더)를 검증하지 못한(혹은 안 한) 경우 이런 일이 발생할 수 있다.
요청이 성공했지만 페이로드가 원본 서버의 200(OK) 응답의 변환 프록시에 의해 수정되었음을 나타낸다.

204 - No Content

응답메세지에서 헤더와 상태줄은 있지만, 엔터티 본문은 없다.
204 응답은 기본적으로 캐시할 수 있다. 그러한 반응에는 ETag 헤더가 포함된다.

일반적인 사용 사례는

사용자에게 표시되는 페이지의 현재 내용을 변경하지 않고 PUT 요청의 결과로 204를 반환하고 리소스를 업데이트하는 것이다.
PUT 요청의 결과로 리소스가 생성되면 201이 대신 반환된다.
페이지를 새로 업데이트된 페이지로 변경해야 하는 경우 200을 대신 사용해야 한다.

205 - Reset Content

브라우저를 위해 사용되는 코드
브라우저에게 현재 페이지에 있는 HTML 폼에 채워진 모든 값을 비우거나, 캔버스 상태를 재설정하거나, UI를 새로 고치도록 지시한다.

206 - Partial Content

부분 혹은 범위 요청이 성공했다.
나중에 우리는 클라가 특별한 헤더를 사용해서 문서의 부분 혹은 특정 범위를 요청할 수 있다는 것을 보게 될 것이다.
이 상태 코드는 범위 요청이 성공했음을 의미한다.
Content-Range헤더와 관련 있다.
206 응답은
- Content-Range와 Date 헤더를 반드시 포함해야 하며,
- Etag와 Content-Location중 하나의 헤더도 반드시 포함해야 한다.

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

클라이언트가 관심 있어 하는 리소스에 대해 다른 위치를 사용하라고 말해주거나, 그 리소스의 내용 대신 다른 대안 응답을 제공한다.
웹서버에서 리다이렉션 코드가 쓰이는 경우에 대한 글은 여기(#5.3) 를 확인해보면된다.

300 - Multiple Choices

클라이언트가 동시에 여러 리소스를 가리키는 URL을 요청한 경우, 그 리소스의 목록과 함께 반환된다.
요청에 둘 이상의 가능한 응답이 있음을 나타낸다.
사용자 에이전트 또는 사용자는 이 중 하나를 선택해야 한다.
응답 중 하나를 선택하는 표준화된 방법이 없기 때문에, 이 응답 코드는 거의 사용되지 않는다.
서버는 Location 헤더에 선호하는 URL을 포함시킬 수 있다.

일반적인 사용 사례는

어떤 서버가 하나의 HTML 문서를 영어와 프랑스어 모두로 제공하는 경우 등에 사용할 수 있다.
클라이언트 주도협상

301 - Moved Permanently

요청된 리소스가 Location 헤더가 지정한 URL로 확실하게 이동되었음을 나타낸다.
브라우저는 이 페이지로 리디렉션 되고 검색 엔진은 그들의 자원 링크를 업데이트한다
따라서 301 코드는 GET 또는 HEAD 방법에 대한 응답으로만 사용하고, 대신 POST 방법에 대한 308 영구 리디렉션을 사용하는 것이 좋다.
이 상태에서는 메서드 변경이 명시적으로 금지되기 때문이다.

302 - Found

요청된 리소스가 Location 헤더가 지정한 URL로 일시적으로 이동되었음을 나타낸다.
브라우저는 이 페이지로 리디렉션 되지만 검색 엔진은 리소스에 대한 링크를 업데이트하지 않는다.
따라서 302 코드는 GET 또는 HEAD 방법에 대한 응답으로만 설정하고, 메서드 변경이 명시적으로 금지되므로 대신 307 임시 리디렉션을 사용하는 것이 좋다.
사용된 메서드를 GET로 변경하려는 경우 대신 **303 “기타”**를 사용해야 한다.

303 - See Other

클라에게 리소스를 다른 URL에서 가져와야 한다고 말해주고자 할 때 쓰인다.
새 URL은 응답메세지의 Location 헤더에 들어있다.
이 코드의 목적은 POST 요청에 대한 응답으로 클라에게 리소스의 위치를 알려주는 것.
이 응답 코드는 보통 PUT 또는 POST의 결과로 반송된다.

304 - Not Modified

클라는 헤더를 이용해 조건부 요청을 만들 수 있다.
만약 클라가 GET과 같은 조건부 요청을 보냈고, 그 요청한 리소스가 최근에 수정된 일이 없다면, 이 코드는 리소스가 수정되지 않았음을 의미하게 된다.
- 리소스가 여전히 최신인지 수정되었는지 검사할 수 있다.
- If-Modified-Since 헤더를 전송한다. (If-None-Match, If-Modified-From)
캐시된 자원으로의 암묵적 리디렉션이다.
이 상태 코드를 동반한 응답은 엔터티 본문을 가져서는 안된다.
200 OK 응답에는 Cache-Control, Content-Location, Date, ETag, Expires, Vary가 포함되었을 것이다.

305 - Use Proxy

306 - 사용되지 않음

307 - Temporary Redirect

Location 헤더로 주어진 URL을 리소스를 임시로 가리키기 위한 목적으로 사용해야 한다.

308 - Permanent Redirect

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

클라이언트는 서버가 다룰 수 없는 무엇인가를 보낸다.
잘못 구성된 요청 메세지 같은 것이 있을 수 있으며, 존재하지 않은 URL 요청도 있을 수 있다.

400 - Bad Request

클라이언트가 잘못된 요청을 보냈다고 말해준다.

401 - Unauthorized

리소스를 얻기 전에 클라에게 스스로 인증하라고 요구하는 내용의 응답을 적절한 헤더와 함께 반환한다.

402 - Payment Required

이 상태 코드는 쓰이지 않지만, 미래에 사용될 수도 있어서 미리 준비해둔 비표준 응답 코드

403 - Forbidden

요청이 서버에 의해 거부되었음을 알려주기 위해 사용된다.
왜 요청이 거부되었는지 서버가 알려주고자 한다면, 그 이유를 설명하는 엔터니 본문을 포함시킬 수 있다.
이 코드는 보통 서버가 거절의 이유를 숨기고 싶을 때 사용한다.
이 상태는 401과 비슷하지만, 로그인 로직(틀린 비밀번호로 로그인 행위)처럼 반응하여 재인증(re-authenticating)을 하더라도 지속적으로 접속을 거절 합니다.

404 - Not Found

서버가 요청한 URL을 찾을 수 없음을 알려주기 위해 사용한다.
404 페이지를 띄우는 링크는 대체로 브로큰 링크(broken link) 또는 **데드 링크(dead link)**라고 부르며, link rot 대상일 수도 있습니다.
404 상태 코드는 리소스가 일시적, 또는 영구적으로 사라졌다는 것을 의미하지는 않다.
리소스가 영구적 삭제되었다면 404 상태 코드 대신 410 (Gone) 상태 코드가 쓰여야 합니다.

405 - Method Not Allowed

요청 URL에 대해, 지원하지 않은 메서드로 요청받았을 때 사용한다.
요청한 리소스에 대해 어떤 메서드가 사용 가능한지 클라에게 알려주기 위해, 요청에 Allow 헤더가 포함되어야 한다.
두 가지 필수 메소드인 GET와 HEAD는 사용 불가능해서는 안 되며, 이러한 오류 타입을 반환해서는 안 됩니다.

406 - Not Acceptable

클라는 자신이 어떤 종류의 엔터티를 받아들이고자 하는지에 대해 매개변수로 명시할 수 있다.
- Accept
- Accept-Charset
- Accept-Encoding
- Accept-Language
주어진 URL에 대한 리소스 중 클라가 받아들일 수 있는 것이 없는 겨우 사용한다.
종종 서버는 클라에게 왜 요청이 만족될 수 없었는지 알려주는 헤더를 포함시킨다.
실제로 이 오류는 거의 사용되지 않는다.
서버는 최종 사용자가 암호화되고 수정하기 어려운 이 오류 코드를 사용하여 응답하는 대신 관련 헤더를 무시하고 사용자에게 실제 페이지를 제공한다.
- 사용자가 완전히 만족하지 않더라도 오류 코드보다 이를 선호할 것으로 추정된다.

407 - Proxy Authentication Required

401 상태코드와 같으나, 리소스에 대해 인증을 요구하는 프락시 서버를 위해 사용한다.

408 - Request Timeout

클라의 요청을 완수하기에 시간이 너무 많이 걸리는 경우, 서버는 이 상태 코드로 응답하고 연결을 끊을 수 있다.
이 타임아웃의 길이는 서버마다 다르지만, 대개 어떠한 적법한 요청도 받아들일 수 있을 정도로 충분히 길다.
408은 서버가 계속 대기하지 않고 연결을 닫기로 결정했음을 의미하므로 서버는 응답에 있는 “닫기” 연결 헤더 필드를 전송해야 한다.
이 응답은 Chrome, Firefox 27+, IE9와 같은 일부 브라우저들이 서핑 속도를 높이기 위해 HTTP 사전 연결 메커니즘을 사용하기 때문에 훨씬 더 많이 사용된다.

409 - Conflict

요청이 리소스에 대해 일으킬 수 있는 몇몇 충돌을 지칭하기 위해 사용한다.
서버는 요청이 충돌을 일으킬 염려가 있다고 생각될 때 이 요청을 보낼 수 있다.
응답은 충돌에 대해 설명하는 본문을 포함해야 한다.
충돌은 PUT 요청에 대응하여 발생할 가능성이 가장 높다. 예를 들어 서버에 이미 있는 파일보다 오래된 파일을 업로드할 때 409의 응답이 발생하여 버전 제어 충돌이 발생할 수 있다.

410 - Gone

404와 비슷하나, 서버가 한때 그 리소스를 갖고 있었다는 점이 다르다.
주로 웹사이트를 유지보수 하면서, 서버 관리자가 클라에게 리소스가 제거된 경우 이를 알려주기 위해 사용한다.
캐시 가능하다.

411 - Length Required

서버 요청 메시지에 Content-Length 헤더가 있을 것을 요구할 때 사용한다.
클라가 서버에 청크 데이터를 보낼때, 서버가 청크 인코딩을 받아들여주지 않을 경우에도 411 Length Required가 내려온다.

412 - Precondition Failed

클라가 조건부 요청을 했는데, 그중 하나가 실패했을 때 사용한다.
조건부 요청은 클라가 Expect 헤더를 포함했을 때 발생한다.
대상 리소스에 대한 액세스가 거부되었음을 나타낸다.
이는 If-Unmodified-from 또는 If-None-Match 헤더에 의해 정의된 조건이 충족되지 않을 때 GET 또는 HEAD 이외의 방법에 대한 조건부 요청에서 발생한다.

413 - Payload Too Large (Request Entity Too Large)

서버가 처리할 수 있는 혹은 처리하고자 하는 한계를 넘은 크기의 요청을 클라가 보냈을 때 사용한다.
서버가 연결을 닫거나 헤더 필드(Retry-After)를 반환할 수 있다.

2. 414 - URI Too Long (Request URI Too Long)

서버가 처리할 수 있는 혹은 처리하고자 하는 한계를 넘은 길이의 요청 URL이 포함된 요청을 클라가 보냈을 때 사용한다.

415 - Unsupported Media Type

서버가 이해하거나 지원하지 못하는 내용 유형의 엔터티를 클라가 보냈을 때 사용한다.

416 - Range Not Satisfiable

요청 메세지가 리소스의 특정 범위를 요청했는데, 그 범위가 잘못되었거나 맞지 않을 때 사용한다.

417 - Expectation Failed

요청에 포함된 Expect 요청 헤더에 서버가 만족시킬 수 없는 기대가 담겨있는 경우 사용한다.

418 - I’m a teapot

서버가 찻주전자이기 때문에 커피 내리기를 거절했다는 것을 의미합니다.
이 오류는 1998년 만우절 농담이었던 하이퍼 텍스트 커피 포트 제어 규약(Hyper Text Coffee Pot Control Protocol)의 레퍼런스입니다.

422 - Unprocessable Entity

이 응답은 서버가 요청을 이해하고 요청 문법도 올바르지만 요청된 지시를 따를 수 없음을 나타냅니다.
클라이언트는 요청을 수정하지 않고 동일한 형태로 다시 보내서는 안된다.

425 - Too Early

서버가 재생될 수 있는 요청을 처리하는 것을 원치 않음을 나타내며, 이는 재생 공격의 가능성을 만든다.

426 - Upgrade Required

서버가 현재 프로토콜을 사용하여 요청을 수행하기를 거부하지만 클라이언트가 다른 프로토콜로 업그레이드한 후 요청을 수행할 의향이 있음을 나타낸다.
서버는 필요한 프로토콜을 나타내기 위해 이 응답과 함께 업그레이드 헤더를 보낸다.

428 - Precondition Required

서버가 요청을 조건부로 해야 함을 나타낸다.
일반적으로 이는 If-Match와 같은 필수 전제 조건 헤더가 누락됨을 의미한다.
전제 조건 헤더가 서버 측 상태와 일치하지 않을 경우 응답은 412 Prefixed가 되어야 한다.

429 - Too Many Requests

사용자가 지정된 시간 동안 너무 많은 요청을 보냈음을 나타낸다.
재시도 후 헤더가 이 응답에 포함될 수 있으며, 이는 새 요청을 하기 전에 대기할 시간을 나타낼 수 있다.

3. 431 - Request Header Fields Too Large

서버가 헤더 필드가 너무 커서 요청을 처리하지 않음을 나타낸다. 요청 헤더 필드의 크기를 줄인 후 요청을 다시 제출할 수 있다.
총 요청 헤더 필드 수가 너무 많은 경우 또는 단일 헤더 필드가 너무 큰 경우 사용할 수 있다.
이 오류는 잘 테스트된 프로덕션 시스템에서 발생해서는 안 되지만, 새로운 시스템을 테스트하는 동안 더 자주 발견될 수 있다.

451 - Unavailable For Legal Reasons

법적 이유로 사용할 수 없는 클라이언트 오류 응답 코드는 사용자가 법적 조치가 발행된 웹 페이지와 같이 법적 이유로 사용할 수 없는 리소스를 요청했음을 나타낸다.

서버 에러 상태 코드 (500 - 599)

클라가 올바른 요청을 보냈음에도 서버 자체에서 에러가 발생하는 경우가 있다.
클라가 서버의 제한에 걸린 것일 수도 있고, 혹은 게이트웨이 리소스와 같은 서버의 보조 구성요소에서 발생한 에러일 수도 있다.
프락시는 클라의 입장에서 서버와 대화를 시도할 때 자주 에러를 만나게 된다.

500 - Internal Server Error

서버가 요청을 처리할 수 없게 만드는 에러를 만났을 때 사용한다.

501 - Not Implemented

클라가 서버의 능력을 넘은 요청을 했을 때 사용한다.
예 서버가 지원하지 않는 메서드를 사용

502 - Bad Gateway

프락시나 게이트웨이처럼 행동하는 서버가 그 요청 응답 연쇄에 있는 다음 링크로부터 가짜 응답에 맞닥뜨렸을 때 사용한다.

1. 503 - Service Unavailable

서버가 요청을 처리해 줄 수 없지만, 나중에 가능함을 의미하고자 할대 사용한다.
서버가 언제 그 리소스를 사용할 수 있게 될지 알고 있다면, 서버는 Retry-After 헤더를 응답에 포함시킬 수 있다.

504 - Gateway Timeout

408과 비슷하지만, 다른 서버에게 요청을 보내고 응답을 기다리다 타임아웃이 발생한 게이트웨이나 프락시에서 온 응답이라는 점이 다르다.

505 - 02. HTTP Version Not Supported

서버가 지원할 수 없거나, 지원하지 않으려고 하는 버전의 프로토콜로 된 요청을 받았을 때 사용한다
몇몇 서버 어플리케이션들은 오래된 버전의 프로토콜을 지원하지 않는 것을 택한다.

511 - 02. Network Authentication Required

클라이언트가 네트워크 액세스를 얻으려면 인증이 필요하다는 것을 나타낸다.
이 상태는 원 서버에서 생성되는 것이 아니라 네트워크에 대한 액세스를 제어하는 프록시를 가로채서 생성된다.
네트워크 운영자들은 때때로 접근을 허가하기 전에 약간의 인증, 용어의 수락 또는 다른 사용자 상호 작용을 요구한다(예: 인터넷 카페나 공항에서).
그들은 종종 자신의 MAC(Media Access Control) 주소를 사용하여 그렇게 하지 않은 클라이언트를 식별한다.