- HTTP 응답에, 어떤 상황에 해당 상태코드가 반환되는지를 보여주는 시각화 다이어그램 자료이다.
상태코드와 사유구절
- 클라이언트에게 그들의 트랜잭션을 이해할 수 있는 쉬운 방법을 제공한다.
=> 상태코드, 사유구절 - HTTP/1.1 기준이다.
상태코드 (HTTP/1.1 기준)
정보성 상태 코드 (100 - 199)
- HTTP/1.1에 도입되었다.
- 복잡함을 감수할만한 가치가 있는지에 대한 논란이 되고 있다.
100 - Continue
- 요청의 시작 부분 일부가 받아들여졌으며, 클라이언트는 나머지를 계속 이어서 보내야 함을 의미한다.
- 이것을 보낸 후 서버는 반드시 요청을 받아 응답해야 한다.
- 클라가 서버에 엔터티 본문을 전송하기 전에
그 엔터티 본문을 서버가 받아들일 것인지 확인하려고 할 때,
그 확인 작업을 최적화하기 위한 의도로 도입된 것이다.
클라이언트와 100 Continue
클라이언트가 엔터티를 서버에게 보내려고 하고, 100 continue 응답을 기다리겠다면, 클라는 Expect 요청 헤더를 보낼 필요가 있다.
1
Expect: 100-continue
최적화를 위한 것이다.
서버가 다루거나 사용할 수 없는 큰 엔터티를 서버에게 보내지 않으려는 목적으로만 사용해야 한다.
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 헤더 고대로 보냄
- 만약 다음 홉서버가(next-hope) HTTP/1.1 이전 버전이라는 걸 알게 되면 417 Expectation Failed를 클라에게 응답한다.
101 - switching protocols
- 클라이언트가 upgrade 헤더에 나열한 것 중 하나로 서버가 프로토콜을 바꾸었음을 의미한다.
- 웹 소켓과 함께 사용될 수 있다.
아래는 upgrade 헤더의 웹소켓으로 서버가 프로토콜을 바꿨다는 의미이다.
1 | HTTP/1.1 101 Switching Protocols |
성공 상태 코드 (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) 주소를 사용하여 그렇게 하지 않은 클라이언트를 식별한다.
- 책뽀개기 모임 중 http 완벽가이드 1장 뽀개기 진행중입니다. (~8월말) (다음 모임은 2장)
(모임 참여를 원하신다면 댓글로 문의 바랍니다.) - HTTP 완벽가이드 책을 보고 이해한 내용을 저만의 순서로 정리 한 글입니다.
참고자료