HTTP 메세지 - 상태코드

출처: http-decision-diagram

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

---

상태코드와 사유구절

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

상태코드 (HTTP/1.1 기준)

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

• 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 에러

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

1. 클라: 서버에게 expect 헤더 보냄
2. 서버: 음! 받을 수 있으니, 100을 보내야겠군
3. 클라: 왜 안 오지 그냥 entity 보내자.
4. 서버: 음? 100 아직 안보냈는데 entity가 왔네. 걍 받자
5. 서버: 잘 받았어 ~ 응답 보내줘야 함
   • 엔터티 읽다가 에러가 나와도, 연결을 닫아서는 안된다.
   • 클라가 응답을 받을 수 없게 되기 때문이다. (?)
     • 아직 잘 모르겠다.

프락시와 100 Continue

1. 클라: 서버에게 expect 헤더 보냄
2. 프락시: 서버에게 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 - HTTP Version Not Supported

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

511 - Network Authentication Required

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

---

• 책뽀개기 모임 중 http 완벽가이드 1장 뽀개기 진행중입니다. (~8월말) (다음 모임은 2장)
  (모임 참여를 원하신다면 댓글로 문의 바랍니다.)
• HTTP 완벽가이드 책을 보고 이해한 내용을 저만의 순서로 정리 한 글입니다.

---

참고자료

1. MDN