Develop/Web

HTTP status code 정리

IJY 2023. 1. 12. 18:59

인프런에 올라와있는 강의 중 모든 개발자를 위한 HTTP 웹 기본 지식(김영한)를 수강 후 HTTP 상태 코드에 대해 짧게 정리한 글입니다.

각 상태 코드에는 더 많은 세부 코드가 존재하지만 자주 사용되는 코드들만 정리를 하였습니다.

그렇기에 혹시나 해당 글에 정리되어 있는 상태 코드가 전부라고 생각하지 않으셨으면 합니다.

(하지만 일반적으로 사용하는 상태 코드 범주 내라면 전부이지 않을까 생각합니다.)

 

1xx - Informational

요청이 수신되어 처리되고 있다는 의미로 사용

하지만 실제로 사용을 거의 하지 않는 상태 코드이므로 이런게 있다 정도만 알고 넘어가면 된다.

 

2xx - Succsessful

요청이 정상적으로 처리 되었다는 의미로 사용

개발 진행 시 내부적으로 어떠한 상태 코드들을 사용할지 의논 후 사용

따라서 202, 204 등의 상태 코드를 사용하지 않고 200 또는 201로 통합해서 사용하는 경우도 빈번

  • 200 OK
    • 요청 성공
  • 201 Created
    • 요청 성공, 새로운 리소스가 생성됨
    • 새로운 리소스는 응답의 Location 헤더 필드에 기록 (또는 바디에 ID 값 포함해서 반환)
  • 202 Accepted
    • 요청이 접수되었으나 아직 처리되지 않았음
    • 배치 처리 같은 곳에서 사용 (요청들이 특정 시간에 한번에 수행한다거나 하는 등)
  • 204 No Content
    • 요청 성공, 응답 페이로드 본문에 보낼 데이터가 없는 경우
    • 문서 저장 기능 등에는 굳이 응답에 내용이 불필요하기에 이러한 경우에 사용

 

3xx - Redirection

요청을 완료하기 위해선 추가적인 행동이 필요하다는 의미로 사용

아래의 상태 코드들의 기본 기능은 간단하게 클라이언트가 응답에 있는 Location 헤더 필드의 경로로 자동으로 이동한다고 보면 된다.

리다이렉션 종류

  • 영구 리다이렉션 : 특정 리소스의 URI가 영구적으로 이동
    • Status code : 301, 308
    • 원래의 URL 사용 금지, 검색 엔징 등에서도 변경 인지하여 수정이 발생
  • 일시 리다이렉션 : 일시적인 변경
    • Status code : 302, 303, 307
    • 일시적 변경이기 때문에 검색 엔진 등에서 수정이 일어나지 않는다.
    • PRG : Post/Redirect/Get
      • Post 후 웹 새로고침을 하는 경우 Post가 재발생하는 문제 발생 (데이터 중복 저장 문제 발생 가능)
      • 따라서 Post에 대한 응답으로 Redirect 상태 코드 사용하여 Get 요청인 URI로 이동하도록 요청
      • 즉, "Post 요청 -> Redirect 응답 -> Get 요청"의 동작이 이루어지므로 새로고침을 하더라도 Get 요청 발생
  • 기타 리다이렉션
    • Status code : 300, 304

세부 상태 코드별 의미

상태 코드별 의미가 동일하더라도 분류가 다르다는 점을 인지하자

  • 300 Multiple Choices
    • 사용 안함
  • 301 Moved Permanently - 영구 리다이렉션
    • 리다이렉트시 요청 메서드가 Get으로 변하고, 본문이 제거될 수 있음 (아닐 수 있다)
  • 302 Found - 일시 리다이렉션
    • 리다이렉트시 요청 메서드가 Get으로 변하고, 본문이 제거될 수 있음 (아닐 수 있다)
  • 303 See Other - 일시 리다이렉션
    • 리다이렉트시 요청 메서드가 Get으로 변경
    • 상태 코드 302와 동일하지만 명시적으로 요청 메서드를 Get으로 변경하라는 의미로 사용
  • 304 Not Modified
    • 캐시를 목적으로 사용
    • 클라이언트에게 리소스가 수정되지 않았으므로 로컬 PC에 저장된 캐시를 재사용하라는 의미 (캐시로 리다이렉트)
    • 캐시를 재사용 하라는 의미이기 때문에 응답에 메시지 바디를 포함하면 안된다.
    • 조건부 Get, Head 요청시 사용
  • 307 Temporary Redirect - 일시 리다이렉션
    • 리다이렉트시 요청 메서드와 본문 유지 (첫 요청이 Post 였다면 리다이렉트 요청에도 Post 유지)
  • 308 Permanent Redirect - 영구 리다이렉션
    • 리다이렉트시 요청 메서드와 본문 유지 (첫 요청이 Post 였다면 리다이렉트 요청에도 Post 유지)

 

애매하게 301, 302 상태 코드의 아닐 수 있다는 점이 존재하는 이유는..

초기에 스펙을 정의할 때 요청 메서드를 유지하도록 정의하였으나 웹 브라우저들이 대부분 메서드를 Get으로 변경해서 보내도록 구현을 하였으며(일부는 다르게 동작), 나중에 이를 알게되었으나 이를 고치기 보다 스펙을 이에 맞춰 변경해버리면서 발생

그래서 명확한 사용을 위해 303, 307, 308 등의 상태 코드가 등장하였고, 이러한 상태 코드 사용을 권장하지만..

이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용하기에 현실적으로 302를 사용해도 큰 문제 없다.

 

4xx - Client Error

잘 못 된 문법등의 이유로 서버에서 요청을 수행할 수 없다는 의미로 사용

즉, 클라이언트에서 요청을 수정하지 않는 한 계속하여 에러 발생

(서버에서 해당 요청에 대해 수행할 수 있는 기능을 만든다면 해결이 될 수 있긴 하겠지만..)

  • 400 Bad Request
    • 클라이언트가 잘못된 요청을 보내어 서버가 처리할 수 없음
    • 요청 구문, 메시지 등등의 오류
  • 401 Unauthorized
    • 클라이언트가 해당 리소스에 접근을 하려면 인증이 필요함
    • 즉, 인증이 안되어 있다는 의미이며, 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명해야 함
    • 상태 코드의 이름이 Unauthorized라서 인가(권한) 문제 아닌가? 싶을 수 있으나 이는 403 상태 코드를 사용
  • 403 Forbidden
    • 서버가 요청을 이해했지만 승인을 거부함
    • 주로 인증은 되어 있으나 권한이 불충분한 경우에 발생
    • 예를 들자면 관리자 페이지를 일반 회원이 접근하려고 하는 경우
  • 404 Not Found
    • 요청 리소스를 찾을 수 없음
    • 서버에 해당 리소스가 없는 경우
    • 또는 권한 문제로 403 상태 코드를 반환해야 하지만 아예 없는 것 처럼 숨기고 싶은 경우에 사용

 

5xx - Server Error

서버단에 문제가 발생하여 요청을 처리할 수 없다는 의미로 사용

즉, 동일한 요청이더라도 서버단의 문제가 해결되면 에러가 발생하지 않을 수 있다는 의미를 내포

  • 500 Internal Server Error
    • 서버 문제로 오류 발생 (NPE, DB 접근 문제 등)
    • 애매하면 해당 상태 코드 사용
  • 503 Service Unavailable
    • 서비스 이용 불가
    • 서버가 일시적으로 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없는 경우 (서버 점검 등)
    • Retry-After 헤더 필드로 얼마 뒤 복구가 되는지 전달 가능

해당 상태 코드의 경우에는 정말로 서버에 문제가 생긴 경우에만 반환하도록 구현해야 한다.

이유로는 모니터링에서 5xx 코드 발생 시 심각한 문제로 파악하는 경우가 많기 때문

그렇기에 일종의 예로써 정상적인 요청이지만 데이터가 없거나 하여 NPE가 발생하거나 한다면 4xx 상태 코드를 사용하거나 2xx 상태 코드를 사용해야 한다.

 

클라이언트에서 알 수 없는 상태 코드를 받는 경우

상태 코드의 큰 범주로 해석하여 처리예를 들자면 아래와 같이 정체를 알 수 없는 상태 코드들에 대한 처리 방식을 보면 쉽게 이해가 가능하다.

  • 299 ??? -> 2xx Successful
  • 451 ??? -> 4xx Client Error
  • 599 ??? -> 5xx Server Error