본문 바로가기
CS

HTTP 상태코드

by sihyeong 2023. 11. 20.

HTTP 상태코드

HTTP 상태코드는 특정 HTTP 요청의 처리 상태응답에서 알려주는 역할을 합니다.

총 5개의 그룹으로 나누어지고 응답, 리다이렉트, 클라이언트 에러, 서버 에러 등을 나타냅니다.

https://datatracker.ietf.org/doc/html/rfc2616#section-10에서 상태코드를 확인할 수 있습니다.

 

아래의 5개 그룹으로 나누어진다.

  • 1xx (Informational): 요청이 수신되어 처리중
  • 2xx (Successful): 요청 정상 처리
  • 3xx (Redirection): 요청을 완료하려면 추가 행동이 필요
  • 4xx (Client Error): 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
  • 5xx (Server Error): 서버 오류, 서버가 정상 요청을 처리하지 못함.

 

만약 클라이언트가 인식할 수 없는 상태코드를 반환한다면

클라이언트는 상위의 상태코드로 변환해서 해석하게 된다.

이렇게 되면 미래에 새로운 상태코드가 추가되어도 클라이언트를 바꾸지 않아도 된다는 장점이 있다.

 

  • 299 -> 2xx (Successful)로 해석
  • 451 -> 4xx (Client Error)로 해석

 

1xx (Informational)

  • 거의 사용하지 않는다.
  • 위의 HTTP 상태코드 사이트에서 확인하면 임시 응답을 나타낼 때 사용한다고 되어있다.
  • 클라이언트가 요청을 계속해야함을 나타냅니다. 클라이언트 요청의 나머지 부분을 계속해서 전송할 때 사용합니다.

2xx (Successful)

  • 요청을 성공적으로 처리했을 경우 반환한다.

200 - OK - 요청 성공

201 - Created - 요청 성공하여 새로운 리소스 생성됨

  • 회원가입 창에서 가입할 회원의 정보를 요청으로 보낸 뒤 해당 리소스를 토대로 회원 정보가 생성된 경우
  • 생성된 리소스는 응답의 Location 헤더 필드에 추가되어 응답된다.
  • Location: /members/100

202 - Accepted - 요청이 접수되었으나 처리가 완료되지 않음

  • 배치 처리와 같은 곳에서 사용된다.
  • 요청후 바로 처리되지 않고 특정 시간에 요청을 처리하는 작업을 할 경우 202 응답을 보낸다.

204 - No Content - 요청을 성공적으로 수행했지만, 응답 본문에 보낼 데이터가 없는 경우

  • 입력 정보를 수정한 경우, 수정의 결과로 응답 데이터가 없어도 2xx 만으로 성공을 인식할 수 있기에 응답 데이터를 보낼 필요가 없고 이럴 때 204 응답을 보내게 된다.

3xx (Redirection)

  • 요청을 완료하기 위해 유저 에이전트의 추가 조치 필요
  • 리다이렉트 수행 시 3xx 응답을 보내게 된다.
  • 웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동하게 된다. (리다이렉트)

리다이렉트가 무슨말인지 이해가 안된다면 리다이렉트를 검색해서 간단하게 보고오길 바란다.

 

 

리다이렉션 종류

리다이렉션의 종류로는 영구, 일시, 특수 리다이렉션이 있다.

 

  • 영구 리다이렉션

특정 리소스의 URI가 영구적으로 이동

원래의 URL를 사용 X, 검색 엔진 등에서도 변경을 인지함.

  • Permanently Moved라고 말하며 해당 URL이 영구적으로 새로운 URL로 변경되었음을 나타낸다. 컨텐츠가 완전히 새로운 URL로 영원히 이동했다고 판단함.
  • naver.com/rank  라는 도메인을 사용하다가 더이상 이러한 도메인을 사용하지 않고 naver.com/newRank 라는 새로운 도메인으로 변경되었을 경우, 기존의 즐겨찾기를 통해 /rank 도메인을 가지고 있던 사용자들은 /rank에 접근하면 301 응답을 받고, URL이 /newRank로 영구적으로 이동되었음을 확인하고 새로운 URL로 이동할 수 있습니다.
  • 일시 리다이렉션 - 특정 리소스의 URI의 일시적인 변경
    • 주문 완료 후 주문 내역 화면으로 이동한다던지 하는 일시적인 URI의 변경에 사용됩니다.
    • Post / Redirect / Get으로 바꿀 때 사용합니다. POST로 주문을 한 경우 Rediect하지 않는다면 새로고침마다 같은 주문이 중복으로 들어가는 문제점이 생기니 이러한 문제를 해결하기 위해 일시 리다이렉션으로 문제를 해결합니다.

영구 리다이렉션 - URI 영구적 이동

301 - Moved Permanently

  • 리다이렉트 시 요청 메서드가 GET으로 변하고, 본문이 제거될 수도 있다.(MAY)

308 - Permanent Redirect

  • 301과 기능은 같음
  • 리다이렉트 시 요청 메서드와 본문을 유지 (처음 POST를 보내면 리다이렉트도 POST를 유지)
  • 301과의 차이점301 요청의 경우 GET 요청이 왔을 때 리다이렉트 후 GET, POST ... 기타 HTTP Method로 변경될 수 있지만, 308은 요청한 HTTP Method와 본문을 유지하며 리다이렉트도 동일한 HTTP Method를 사용하게 된다는 차이점을 가진다.

일시적 리다이렉션 - URI 일시적 변경

302 - Found

  • 301과 비슷하게 리다이렉트 요청 시 메서드가 GET으로 변하고, 본문이 제거될 수도 있다.(MAY)

307 - Temporary Redirect

  • 302와 기능은 같음
  • 리다이렉트 시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안됨)
  • 308의 특성과 동일하게 요청 메서드와 본문을 유지함

303 - See Other

  • 302와기능은 같음
  • 리다이렉트 시 요청 메서드가 GET으로 변경됨
  • 307은 동일한 요청메서드를 가지지만, 303은 무조건 리다이렉트 요청 메서드가 GET으로 변경되어 동작된다. 

302 Found: GET으로 변경 가능

307 Temporary Redirect: 메서드 변경 X

303 See Other: 메서드가 GET으로 무조건 변경

 

기타 리다이렉션

300 - Multiple Choices - 안씀

304 - Not Midified - 캐시를 목적으로 사용

  • 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 클라잉너트는 로컬 PC에 저장된 캐시를 재사용한다.
  • 304 응답은 메시지 바디를 포함하지 않는다. 클라이언트의 로컬 캐시를 사용하므로

4xx (Client Error)

  • 클라이언트 오류
  • 클라이언트가 요청할 때 잘못된 문법이나 잘못된 데이터를 요청하거나 하면 발생한다.
  • 오류의 원인이 클라이언트에게 있다.

400 - Bad Request

  • 클라이언트가 잘못된 요청을 해서 서버가 처리할 수 없음
  • 잘못된 요청 파라미터, API 스펙이 맞지 않는 경우 발생 가능

401 - Unauthorized

  • 클라이언트가 해당 리소스에 대한 인증이 필요함
  • 인증되지 않았을 경우 발생함
  • 오류 발생 시 응답에 www-authenticate 헤더와 함께 인증 방법을 설명한다.

403 - Forbidden

  • 서버가 요청을 이해했지만 승인을 거부함
  • 주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우 발생한다.
  • 스프링 시큐리티에서 역할을 나누고 상위 리소스에 접근하는 경우 403으로 접근을 막는다.

404 - Not Found

  • 요청 리소스가 없을 때 사용한다.
  • 클라이언트의 권한이 부족한 리소스에 접근할 때 리소스를 숨기기 위해 사용하기도 한다.

5xx (Server Error)

  • 서버 오류
  • 서버에 문제가 발생했기 때문에 서버에서 문제를 해결한다면 재 시도할 경우 성공할 수 있음

500 - Internal Server Error

  • 서버 문제로 발생, 서버의 문제 중 애매하면 500 발생

503 - Server Unavailable

  • 서비스 이용 불가
  • 서버의 일시적인 과부하, 예정된 작업으로 잠시 요청을 처리할 수 없을 경우 발생
  • Retry-After 헤더 필드로 얼마 뒤 복구되는지 보낼 수 있다.

 

웹이 어떤식으로 동작하는지 알기 위해 HTTP 상태코드를 공부하며 정리했습니다.

상태코드를 몰라도 Spring MVC에서 추상화되어 자동으로 상태코드를 만들어 제공해 주지만,

디버깅, 동작원리 학습을 통해 더 나은 구조의 코드를 작성하기 위해 학습을 진행했습니다.

 

공부를 하고 나니 웹 개발자를 하겠다며

200, 404밖에 몰랐던 지난날의 제가 부끄러워 집니다.

 

TCP/IP를 공부할 때 enum값으로 처리 방식을 구분했었는데

체계적으로 정리된 HTTP 상태코드를 보니 제가 작성한 코드가 부끄러워집니다.

 

항상 느끼는 것이지만, 시간이 좀 걸리더라도 기본지식이나 동작원리를 공부하는 것이 정말 많은 도움이 되는 것 같습니다.

 

'CS' 카테고리의 다른 글

HTTP Method  (1) 2023.11.14