HTTP Status Code

이번 글에서는 HTTP 상태코드에 대해 이야기 하겠다

 

* 상태코드

: 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능

 

상태코드는 크게 봤을 때 다음과 같이 존재한다.

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

 

아래는 각 상태코드의 상세설명이다.

 

1. 1xx

• 요청이 수신되어 처리중임을 나타냄
• 거의 사용하지 않음

 

2. 2xx

• 클라이언트의 요청을 성공적으로 처리했음을 나타냄
• 200 OK
  • 요청 성공

 

• 201 Created 
  • 요청 성공해서 새로운 리소스가 생성됨
  • POST Method를 사용했을 때 발생

• 202 Accepted
  • 요청이 접수되었으나 처리가 완료되지 않음
  • 예) 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리하는 경우

• 204 No Content
  • 서버가 요청을 성공적으로 처리했지만, 응답 페이로드 본문(HTTP Message Body)에 보낼 데이터가 없음
  • 서버에서 요청 처리 후, 클라이언트에게 전달할 데이터가 없을 경우 발생
  • 예) 웹 문서 편집기에서 save버튼을 눌렀을 때
    • save버튼을 눌렀을 때, 서버는 편집기에 있는 글을 저장하지만
    • 클라이언트에게 Data를 전달할 필요 없음
  • 결과 내용이 없어도 204 메시지(2xx)만으로 성공으로 인식 할 수 있다.

 

3. 3xx

• Rediection
  • Location 헤더가 있으면, Location 위치로 자동 이동(Redirect)

 

• Redirection에는 다음과 같은 종류가 존재한다
  • 영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동
    • 예) /members -> /users
    • 예) /event -> /new-event
  • 일시 리다이렉션 - 일시적인 변경
    
    • PRG - POST/Redirect/GET
    • 예) 주문 완료 후 주문 내역 페이지로 이동
      • POST: 주문요청
      • Redirect: 주문내역 페이지 URI 전달(상태코드 3xx)
      • GET: 클라이언트에서 주문내역 페이지로 이동
  • 특수 리다이렉션
    
    • 결과 대신 캐시를 사용
    • 캐시 사용이 가능할 경우 사용
    • 클라이언트가 동일한 요청을 할 경우 캐시에 저장된 결과를 전달

 

다음은 Redirection 상태코드에 대한 상세설명이다.

 

1) 영구 리다이렉션 - 301, 308

• 301, 308 모두 동일한 기능을 갖고 있음
• 리소스의 URI가 영구적으로 이동
• 기존 URL이 더 이상 존재하지 않음
• 원래의 URL를 사용X
• 검색엔진 등에서도  변경 인지하여 변경된 주소로 Redirect

   
    a. 301 - Moved Permanently

• 리다이렉트 시 요청 메서드가 GET으로 변하고, Http Message Body가 제거될 수 있음(May)

   

b. 308 - Moved Permanently

• 301과 기능은 같음
• 리다이렉트 시 요청 메서드와 본문 유지
  (처음 POST를 보내면 리다이렉트도 POST 유지)

 

2) 일시적인 리다이렉션 - 302, 307, 303

• 리소스의 URI가 일시적으로 변경
• 기존 URL 존재하는 상태
• 따라서, 검색 엔진 등에서 URL을 변경하면 안 됨

PRG - POST/Redirect/GET

    a. PRG 사용 전

• POST로 주문 후 새로고침 하면?
• 새로고침 시 다시 주문요청을 하게 됨
• 중복으로 주문이 될 수 있다.

 

    b. PRG 사용 후

• POST로 주문 후에 새로고침으로 인한 중복 주문 방지
• POST로 주문 후에 주문결과 화면을 GET 메서드(조회)로 리다이렉트
• 새로고침해도 결과화면을 GET으로 조회
• 중복주문 대신에 결과 화면만 GET으로 다시 요청

 

• 302 Found: 리다이렉트 시 요청 메서드가 GET으로 변할 수 있음(May)
• 307 Temporary Redirect: 리다이렉트 시 요청 메서드가 변하면 안 됨
• 303 See Other: 리다이렉트 시 요청 메서드가 변경(Must)

 

• 302의 경우 리다이렉트 시 요청 메서드가 바뀔 수도, 안 바뀔 수도 있음
• 그래서 모호한 302를 대신하는 307, 303이 등장함

3) 특수 리다이렉션 - 300, 304

• 300 Multiple Choices
  • 한 요청에 대해 다수의 응답이 존재함을 나타냄
  • 현재는 잘 쓰지 않음
• 304 Modified
  • 캐시를 목적으로 사용
  • 클라이언트가 기존과 동일한 요청을 한적이 있을 때 리소스가 수정되지 않았음을 알려준다
  • 상태코드 304를 받았을 경우, 클라이언트가 로컬PC에 저장된 캐시를 재사용 한다(캐시로 리다이렉트 한다)
  • 304 응답은 HTTP Message Body를 포함하면 안 된다(로컬 캐시를 사용해야 하므로)
  • 조건 부 GET, HEAD 요청 시 사용

 

4. 4xx

• 클라이언트가 잘못된 요청을 할 경우
• 에러의 원인이 클라이언트에게 있음
• 이미 잘못된 요청/데이터를 보내고 있기 때문에, 몇 번이든 계속 동일한 재시도를 할 경우 에러가 발생

    a. 400 Bad Request

• 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
• 클라이언트는 요청 내용을 다시 검토하고 보내야함

 

    b. 401 Unauthorized

• 요청하고자 하는 클라이언트의 신원이 확인되지 않은 경우
• 401 에러 발생 시, 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명

• 참고
  • 인증(Authentication): 본인이 누구인지 확인 - "당신은 누구?" ex) 로그인
  • 인가(Authorization): 권한부여 - "해당 리소스에 접근할 권한이 있나?"

 

    c. 403 Forbidden

• 서버가 요청을 이해했지만 승인을 거부
• 주로 자격 증명은 있지만, 접근 권한이 불충분한 경우
  (인증은 되었으나, 인가가 안된경우)
• 예) Admin 등급이 아닌 사용자가 로그인은 했지만, Admin 등급의 리소스에 접근하는 경우

 

    d. 404 Not Found

• 요청하고자 하는 리소스가 서버에 없음
• 클라이언트가 권한이 부족한 리소스에 접근하는 것을 방지하기 위해 리소스를 숨기고 싶을 때도 사용

 

5. 5xx

• 서버 문제로 에러 발생
• 에러의 원인이 서버에 있음
• 서버에 문제가 있기 때문에 재시도 하면 요청이 성공할 수도 있음(서버가 복구되었을 경우)

 

    a. 500 Bad Request

• 서버 내부 문제로 에러 발생

    b. 503 Unauthorized

• 서버의 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음
• Retry-After 헤더 필드로 얼마 뒤에 복구되는지 보낼 수도 있음