HTTP 상태코드

김영한님의 모든 개발자를 위한 HTTP 웹 기본 지식을 수강하면서 HTTP 내용을 정리한다.

자세한 정보가 궁금하면 수강을 추천드립니다.

모든 개발자를 위한 HTTP 웹 기본 지식 - 인프런 | 강의

---

HTTP 상태코드 소개

클라이언트가 서버로 보낸 요청의 처리 상태를 알려주는 기능 

- 1xx (Informational) : 요청이 처리되어 수신 중 (거의 사용안함)

- 2xx (Successful) : 요청 정상 처리

- 3xx (Redirection) : 요청을 완료하려면 추가 행동이 필요

- 4xx (Client Error) : 클라이언트 오류, 잘못된 문법등으로 서버가 요청 수행을 못함

- 5xx (Server Error) : 서버 오류, 서버가 정상 요청을 처리 못함 

 

만약에 모르는 상태 코드가 나타나면?

몇번대 상태코드인지만 보고 파악하자.

- 1xx 처리중이구나

- 2xx 성공했구나

- 4xx 클라이언트 오류구나

- 5xx 서버 오류구나

---

2xx (Successful)

클라이언트 요청을 성공적으로 처리

- 200 ok : 요청을 성공했다는 뜻, 단순 조회 요청에 자주 접함 

- 201 Created : 리소스 등록 요청에 성공 

- 202 Accepted : 요청이 접수되었지만 처리가 안된 상태 (잘 사용안함) 

ex) 배치 요청 

- 204 No Context : 서버가 요청을 수행했지만, 응답으로 보낼 데이터가 없음.

ex) 문서 작업 중 save 눌러도 아무 변화없음, 결과 내용이 없어도 204 응답 메시지로 성공 인식 가능

 

* 200만 사용하는 회사도 있고 200,201을 같이 사용하는 회사도 있음. 회사마다 정하는 규칙에 따라 다름.

---

3xx (Redirection) 

요청을 완료하기 위해 유저 에이전트(웹 브라우저를 뜻함)의 추가 조치 필요

- 300 Multiple Choices

- 301 Moved Permanently

- 302 Found

- 303 See Other

- 304 Not Modified

- 307 Temporary Redirect 

- 308 Permanent Redirect

 

리다이렉션의 이해

웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, 해당 Location로 이동한다.

* 리다이렉트라고 말하기도 함.

리다이렉트의 흐름

1. 클라이언트가 요청을 보낸다.

2. 서버가 요청을 처리하고 3xx 상태코드와 Location 경로를 보내준다.

3. 웹 브라우저가 상태코드와 Location을 보고 해당 경로로 자동으로 요청을 보내고 응답을 받는다.

4. 너무 빨라서 사용자의 입장에서는 인식을 하기 힘들다.  

리다이렉션의 종류

- 영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동

ex) /members -> /users, /event -> /new-event

 

- 일시 리다이렉션 - 일시적인 변경 (PRG: Post/Redirect/Get)

ex) 주문 완료 후 주문 내역 화면으로 이동

 

- 특수 리다이렉션 : 결과 대신 캐시를 이용

 

영구 리다이렉션

301, 308 상태코드를 가짐

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

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

- 301 Moved Permanently

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

301은 메시지가 제거된다.

- 308 Permanent Redirect

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

301과 다르게 HTTP 메서드와 본문이 유지

 

* 301 위주로 사용함, 요청 데이터까지 유지해야 할 이유가 별로 없기 때문  

일시적인 리다이렉션

302, 307, 303 상태코드를 가짐

- 리소스의 URI가 일시적으로 변경, 영구적인 리다이렉션과 다르게 검색엔진 등에서 URL 변경하면 안됨.

- 302 Found

    - 리다이렉트시 요청 메시지가 GET으로 변하고, 본문이 제거될 수 있음(MAY)

- 307 Temporary Redirect

    - 302와 기능은 같음, 리다이렉트시 요청 메서드와 본문 유지 (요청 메서드 변경하면 안됨) 

- 303 See Other

    - 302와 기능은 같음, 리다이렉트시 요청 메서드가 GET으로 변경 

 

 

일시적인 리다이렉션 - 예시

 

- POST로 주문 후에 웹 브라우저를 새로고침하면?

- 새로고침은 다시 등록 요청을 하게 됨 -> 중복 주문이 될 수 있다. 

* 게시글이나 댓글을 등록할 때, 새로고침하면 중복으로 등록되는 경험을 겪어볼 수도 있다. 

중복 등록되는 모습

 

중복을 막는 PRG: POST/Redirect/Get 

- POST로 주문후에 새로고침으로 인한 중복 주문 등록 방지

- POST로 등록 요청 후에 결과화면을 GET 메서드로 리다이렉트 (Post/Redirct/Get)

- 새로고침해도 등록 요청이 아닌 결과화면만 GET 조회하게 됨

중복이 막힌 상태

302, 307, 303 뭘 써야 할까요?

역사

- 처음의 302 스펙의 의도는 HTTP 메서드를 유지하는 것, 하지만 웹 브라우저들이 대부분 GET으로 바꿔버림. (일부는 다르게 동작)

- 302 대신 307, 303이 등장하게 됨.

 

현실

- 307, 303을 권장해도 많은 애플리케이션 라이브러들이 302를 기본값으로 사용함

- 자동 리다이렉션시에 GET으로 변해도되면 그냥 302 사용해도 무방할 정도. 

 

기타 리다이렉션

- 300 Multiple Choices: 안씀

- 304 Not Modified

    - 캐시 목적으로 사용, 서버는 클라이언트에게 수정되지 않음을 알려줌

    - 로컬 PC에 저장된 캐시로 리다이렉트해서 재사용함.

    - 로컬 캐시를 사용해야 하니 응답에 메시지 바디를 포함안함.

    - 조건부 GET, HEAD 요청시에 사용함

---

4xx (Client Error)

클라이언트의 오류일 경우 사용

- 클라이언트가 잘못된 요청으로 서버가 요청을 수행할 수 없을 경우 (오류의 원인이 클라이언트)

- 같은 요청을 보내도 계속 실패함. 

* 서버에서 유효성 검사로 철저하게 쳐냄 

 

400 Bad Request

- 요청 구문, 메시지 등등 오류

- 클라이언트는 요청을 재검토해서 보내야함.

 

401 Unauthorized

클라이언트가 해당 리소스에 대한 인증이 필요함 

- 인증되지 않음

- 401 오류 발생 시 응답에 WWW-Authenticate 헤더와 함께 인증 방법을 설명

참고

- 인증(Authentication) : 본인이 누구인지 확인 ex) 로그인

- 인가 (Authorization) : 권한 여부 확인 ex) 접근 권한

- 오류 메시지가 Unauthorized 이지만 인증되지 않음

 

403 Forbidden

서버가 요청을 이해했지만 승인을 거부함

- 인증은 되지만, 접근 권한이 안 되는 경우 ex) 일반 관리자가 최고 등급 관리자 리소스에 접근할 경우

 

404 Not Found

요청 리소스를 찾을 수 없음

- 요청 리소스가 서버에 없음

- 또는 해당 리소스를 숨기고 싶을 때

404 에러 

---

5xx (Server Error)

서버 오류

- 서버 문제로 오류가 발생

- 4xx와 다르게 재시도하면 성공할 수도 있음 (서버가 복구되면)

* 참고 : 결제 요청 시 고객의 잔액이 부족하면 5xx 에러를 내면 안 된다.

 

500 Internal Server Error

서버 문제로 오류 발생, 애매하면 모두 500 에러

 

503 Service Unavailable

서비스 이용 불가

- 서버가 과부하 되었거나, 배포 작업 등으로 이용 못할 경우 사용

- Retry-After 헤더 필드로 언제 복구되는지 보낼 수도 있음.