HTTP 완벽가이드 3장 - 3. HTTP 상태코드

: 클라이언트에게 서버에서 무슨일이 일어났는지 말해주는 것

• 사람이 읽기 편한 사유구절(OK, CREATED)과는 다르게 숫자로 되어있어 프로그램이 에러처리하기에 용이
• 대략적인 구성: 일반적으로 아래의 구성을 따른다. 따라서, 누군가 상태코드를 확장해 사용하더라도 아래의 범주내에 속한다면 해당 관련 내용으로 이해해야 한다.
  • 100~199: 정보
  • 200~299: 성공
  • 300~399: 리소스 옮겨짐(리다이렉션)
  • 400~499: 클라이언트 에러(잘못된 요청)
  • 500~599: 서버 에러

100 - 199 : 정보성 상태 코드

• HTTP/1.1에서 도입

100 Continue

• 요청의 시작부분 일부가 받아들여짐
• 애플리케이션이 서버에 엔터티 본문을 전송하기 전에 그 본문을 서버가 받아들일지를 확인
• 이것을 보낸 후 서버는 반드시 요청을 받아 응답해야 한다.

클라이언트

• 클라이언트는 100-continue라는 expect 헤더를 보내고, 100 Continue 상태코드를 받을 것을 기다린다. 그러나, 응답을 막연히 기다리기만 해서는 안되고, 약간의 타임아웃 후에 그냥 엔터티를 보내야 한다.
• 엔터티 본문을 보내지 않으려면 expect 헤더를 보내지 않아야 한다.

서버

• 서버는 100-continue 응답을 받을 것을 의도하지 않은 클라이언트에게 이 상태코드를 보내서는 안된다.

• 어떠한 이유로 이미 엔터티를 수신했다면, 이 상태코드를 보낼 필요가 없다.

• (에러 등의 이유로) 서버가 엔터티 본문을 읽기전에 요청을 끝내기로 결정했다면, 그서버는 그냥 응답을 보내고 연결을 끊어서는 안된다.

  TCP 끊기와 리셋 에러를 살펴보기

프록시

• 넥스트 홉 (전달할 다음 서버)가 HTTP/1.1을 따르거나, 어떤 버전을 따르는지 모른다면 Expect 헤더 포함시켜 보낸다.
• 넥스트 홉 서버가 이전 버전을 따른다는 것을 안다면 클라이언트에게 417 Expectation Failed 에러로 응답.
• 마찬가지로, 클라이언트가 이전 버전을 따른다는 것을 안다면, 100 Continue 응답을 클라이언트에게 전달해서는 안된다.

101 Switching Protocols

• 서버가 프로토콜을 바꾸었음을 의미

200 - 299 : 성공 상태 코드

200 OK

• 요청은 정상이고 엔터티 본문은 요청된 리소스를 포함하고 있음

201 Created

• 서버에 개체를 생성하라는 요청(주로 POST, PUT에 대한 응답)
• 주로 생성된 리소스에 대한 구체적인 참조 Location 헤더(엔터티 정보 헤더 중 하나), 리소스를 참조할 수 있는 여러 URL을 엔터티 본문에 포함
• 상태코드 보내기에 앞서 반드시 객체를 생성해야함.

202 Accepted

• 요청은 받아들여졌지만, 서버는 아직 그에 대한 어떠한 동작도 수행하지 않음(무엇을 할 것인지도 모름)
• 요청이 받아들여지기에 적합하다는 것을 보임

203 Non-Authoritative Information

• 서버의 실제 리소스가 아닌 사본
  • 프록시가 리소스의 사본을 갖고 있다가 전달한 것 등
  • 따라서 메타 정보(헤더)를 검증하지 못한 경우이다.

204 No Content

• 응답 메시지는 시작줄과 헤더를 포함하고 엔터티 본문 포함X

205 Reset Content

• 브라우저에게 현재 페이지에 있는 HTML 폼의 모든 값을 비우라고 말한다.

206 Partial Content

• 부분 혹은 범위 요청 성공

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

• 클라이언트가 요청하는 리소스에 대해 다른 위치를 사용하라고 말해주거나, 리소스의 내용 대신 다른 대안 응답
• 만약 리소스가 옮겨졌다면, 옮겨진 위치(Location 헤더)를 보낼 수 있다.
  • 받은 브라우저는 알아서 새 위치로 이동시켜줌
• 일반적으로 이 상태코드와 함께 응답을 보낼때는 리다이렉트 될 URL에 대한 링크와 설명을 포함시키는 것이 좋은 습관

300 Multiple Choices

• 여러 리소스를 가리키는 URL을 요청한 경우, 리소스의 목록과 함께 반환
• Location 헤더에 선호하는 URL을 포함시킨다.
• 목록 중 하나를 사용자가 선택

301 Moved Permanently

• 요청 URL이 옮겨졌을 때 사용.
• Location 헤더에 현재 리소스의 위치 URL을 포함해야한다.

302 Found

• 301과 같으나, 요청한 리소스의 URI가 일시적으로 변경되었음을 의미

303 See Other

• 리소스를 다른 URL에서 GET 요청을 통해 얻어야 할 때 사용
• 새 URL은 응답 메시지의 Location 헤더에 존재

304 Not Modified

• 캐싱되어있는 리소스가 수정되지 않았다면, 클라이언트는 이것을 받고 계속해서 캐시된 버전을 사용하면 됨

305 Use Proxy

• 보안을 목적으로, 리소스를 반드시 Proxy를 통해 접근해야 함을 나타낸다.
  • 프록시의 위치는 Location 헤더에 존재

307 Temporary Redirect

• 302 Found와 동일한 의미.

302, 303, 307의 관계

• HTTP/1.0 클라이언트가 POST 요청을 보내고 302를 받으면, Location 헤더의 리다이렉트 URL을 GET 요청으로 따라갈 것이다.
• HTTP/1.1에서는 그러한 리다이렉션에 303을 사용한다.
• 이 혼란을 막기 위해 HTTP/1.1에서는 일시적인 리다이렉트를 위해 302 대신 307을 사용
  • 여전히 302는 HTTP/1.0를 위해 남겨놓음
• 서버는 적절한 상태 코드를 선택하기 위해 클라이언트의 HTTP 버전을 검사할 필요가 있다.

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

• 많은 클라이언트 에러가 브라우저에 의해 처리

400 Bad Request

• 클라이언트가 잘못된 요청을 보냈다고 말해줌
• Invalid parameter 등

401 Unauthorized

• 클라이언트에게 스스로를 인증하라고 요구하는 것

402 Payment Required

• 아직 사용되지 않고, 미래를 위해 만들어 둔 것.
• 디지털 결제 시스템에 사용될 것

403 Forbidden

• 요청이 서버에 의해 거부되었음
• Reason을 엔터티 본문에 포함시킬 수 있음. 그러나, 보통 서버가 거절의 이유를 숨기고 싶을 때 사용
• 401과는 다르다.(서버 입장에서 클라이언트가 누군지는 알고 있음)

404 Not Found

• 요청받은 URL에 해당하는 리소스를 찾을 수 없음
• 이 경우 엔드포인트는 적절하지만, 리소스 자체는 존재하지 않음을 의미할 수도 있음

405 Method Not Allowed

• 요청한 URL에 대해 지원하지 않는 메서드로 요청 받았을 때
  • 예를들어 어떤 리소스를 삭제하는 것을 금지해놓을 수 있다.
• Allow 헤더(엔터티 정보 헤더 중 하나)가 포함되고, 여기에 어떤 메서드가 허용되는지가 포함되어야 한다.

406 Not Acceptable

• 서버주도 콘텐츠 협상 이후, User agent에서 정해준 규격에 따른 어떠한 콘텐츠도 찾지 못했을 때
  • 콘텐츠 협상: 사용자 에이전트가 사용자에게 제일 잘 맞는 것이 무엇인지(문서의 언어, 이미지 포맷 혹은 인코딩 등에 있어 어떤 것이 적절한지) 협상하는 것
  • 주어진 URL에 대한 리소스 중 클라이언트가 받아들일 수 있는 것이 없는 경우

407 Proxy Authentication Required

• 401과 같으나, 프록시에 의한 인증이 필요

408 Request Timeout

• 클라이언트의 요청을 완수하기에 시간이 너무 많이 걸리는 경우, 서버는 이 상태코드로 응답하고 연결을 끊음

409 Conflict

• 요청이 현재 서버에 충돌을 일으킬 염려가 있다고 생각될 때

410 Gone

• 404와 비슷하나, 서버가 한때 그 리소스를 갖고있었는데 제거된 경우

411 Length Required

• 서버가 필요로하는 Content-Length 헤더 필드가 요청 메시지에 정의되지 않은 경우

412 Precondition Failed

• 클라이언트가 조건부 요청을 했는데 그 중 하나가 실패했을 때

417 Expectation Failed

• Expect 헤더에 서버가 만족시킬 수 없는 expect가 담겨있는 경우

500 - 599 : 서버 에러 상태 코드

• 프락시는 서버의 문제를 설명하기 위해 500번대 서버 에러 상태 코드를 생성한다.

500 Internal Server Error

• 서버가 요청을 처리할 수 없게 만드는 에러를 만났을 때

501 Not Implemented

• 서버가 처리 방법을 모를 때 e.g) 서버에서 지원하지 않는 메서드를 요청에 사용한 경우

502 Bad Gateway

• 게이트웨이나 프락시가 잘못된 응답을 얻은 경우. e.g) 부모 게이트웨이에 접속이 불가능할 때

503 Service Unavailable

• 현재는 요청을 처리해줄 수 없지만, 나중에 가능한 경우
• 나중이 언제일지를 안다면 Retry-After 헤더를 응답에 포함

504 Gateway Timeout

• 408 Request Timeout과 비슷하지만, 게이트웨이나 프락시가 응답을 기다리다 타임아웃이 난 경우

505 HTTP Version Not Supported

• 서버가 지원할 수 없는 버전의 프로토콜 요청을 받았을 때

Reference)

HTTP 완벽가이드

https://developer.mozilla.org/ko/docs/Web/HTTP/Status