[네트워크] HTTP 기초 - HTTP 상태 코드
HTTP 상태코드
1. HTTP 상태코드 소개
상태 코드는 클라이언특 ㅏ보낸 요청의 처리 상태를 응답에서 알려주는 기능이다. 크게 다섯가지로 나눌 수 있다.
- 1XX (Informational) : 요청이 수신되어 처리중
- 2XX (Successful) : 요청 정상 처리
- 3XX (Redirection) : 요청을 완료하려면 추가 행동이 필요
- 4XX (Client Error) : 클라이언트 오류, 잘못된 문법등으로 서버가 요청을 수행할 수 없음
- 5XX (Server Error) : 서버 오류, 서버가 정상 요청을 처리하지 못함
클라이언트가 만약 인식할 수 없는 상태 코드를 서버가 반환한다 하더라도 클라이언트는 상위상태코드로 해석해서 처리한다.
1XX (Informational)는 요청이 수신되어 처리중인 의미이므로 거의 볼 일이 없다. 거의사용하지 않으므로 생략한다.
2. 2XX - 성공
- 200 OK
- 201 Created : 요청 성공해서 새로운 리소스 생성 예)POST 등록
- 202 Accepted : 요청이 접수되었으나 처리가 완료되지 않았음, 배치 처리 같은 곳에서 사용
- 204 No Content : 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음
204의 경우, 예로 웹 문서 편집기에 아무 내용을 입력하지 않고 저장 버튼을 누를 수 있다. 그때 아무 내용이 없어도 204 메시지(2XX)만으로 성공을 인식할 수 있다.
실무에서 저 네 개 다 사용하지 않고 팀에서 사용 범위를 정하여 쓴다. 보통 200만 쓰거나 201까지 쓴다.
3. 3XX 리다이렉션
3XX대 리다이렉션은 클라이언트로부터 요청을 받았는데 완료하기 위해서 추가 조치가 필요한 경우를 말한다.
- 웹 브라우저는 3XX 응다브이 결과에 Location 헤더가 있으면, Location 위치로 자동 이동한다.
리다이렉션은 다음과 같이 세 종류가 있다.
- 영구 리다이렉션 : 특정 리소스의 URI가 영구적으로 이동
- 일시 리다이렉션 : 일시적인 변경, 예로 주문 완료 후 주문 내역 화면으로 이동하는 경우
특수 리다이렉션 : 결과 대신 캐시를 사용
영구 리다이렉션은 원래의 말 그대로 영구적으로 이동하며 원래 URL을 사용하지 않고 검색 엔진 등에서도 변경을 인지한다. 301 Moved Permanently 와 308 Permanent Redirect 둘이 있는데 영구 이동하는 기능은 같다. 그러나 301은 리다이렉트시 요청 메서드가 GET으로 변하고 본문이 제거될 수도 있다. 308은 리다이렉트시 요청 메서드와 본문 유지(처음 POST를 보내면 리다이렉트도 POST)한다. 그러나 영구적인 리다이렉션보다 일시적인 리다이렉션을 많이 사용하는 편이다.
일시적인 리다이렉션은 URI가 일시적으로 변경되는 것으로 검색 엔진 등에서 URI을 변경하면 안된다. 일시적인 리다이렉션에 해당되는 번호가 3개 있는데 302 Found, 307 Temporary Redirect, 303 See Other가 있다. 302 Found는 앞서 301처럼 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다. 307 Temporary Redirect는 308처럼 리다이렉트시 요청 메서드와 본문 유지된다.(요청 메서드를 변경하면 안된다.) 303 See Other는 리다이렉트시 요청 메서드가 GET으로 변경한다. 이 셋 중 302를 주로 많이 사용한다.
이런 일시적인 리다이렉션이 써야하는 경우는 주문 후 새로고침등으로 중복 주문을 막기 위할 때 사용한다. 보통 PRG(Post/Redirect/Get)이라고 한다.
정리하자면- 302 Found -> GET으로 변할 수 있음
- 307 Temporary Redirect -> 메서드가 변하면 안됨
- 303 See Other -> 메서드가 GET으로 변경
현실에서는
- 307, 303을 권장하지만 현실적으로 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용
- 자동 리다이렉션시에 GET으로 변해도 되면 그냥 302를 사용해도 큰 문제 없음
이 이외에 사용하는 기타 리다이렉션은 304 Not Modified가 있는데 캐시를 목적으로 사용된다. 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 그래서 클라이언트는 로컬PC에 저장된 캐시를 재사용한다. 캐시를 사용하기 때문에 서버의 부담이 줄어든다. 로컬 캐시를 사용해야하므로 304 응답은 메시지 바디를 포함하면 안된다. 조건부 GET, HEAD 요청시 사용한다.
4. 4XX - 클라이언트 오류, 5XX - 서버오류
4XX 오류는 클라이언트에 오류가 있는 것이고 5XX 오류는 서버에 문제가 생기는 오류이다.
우선 4xx 오류를 먼저 보면 클라이언트의 요청에 잘못된 문법등으로 서버가 요청을 수행할 수 없는 상태이다. 그래서 클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에 똑같은 재시도를 해도 실패한다. 반면 5XX 오류는 데이터베이스 문제로 안됐다가 복구가 되면 될 수도 있는 가능성이 있다. 요청 구문, 메시지, 잘못된 파라메터 수신 등 클라이언트의 요청 내용을 다시 검토하고 보내야 한다. 4XX 오류 종류로 아래 3가지가 있다.
- 401 Unauthorized: 클라이언트가 해당 리소스에 대한 인증이 필요함
- 인증(Authentication) 되지 않음, 401 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증방법 설명
- 인증(Authentication) : 본인이 누구인지 확인(로그인)
- 인가(Authorization) : 권한부여 (ADMIN 권한처럼 특정 리소스에 접근할 수 있는 권한, 인증이 있어야 인가가 있음)
- 403 Forbidden : 서버가 요청을 이해했지만 승인을 거부함. 주로 인증 자걱 증명은 있지만, 접근 권한이 불충분한 경우. 예) Admin 등급이 아닌 사용자가 로그인하고 Admin 등급 리소스에 접근한 경우
- 404 Not Found : 아주 친숙한 오류 번호 404 요청 리소스를 찾을 수 없음. 또는 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을때 사용할 수도 있다.
이제 5XX 서버 오류를 보면 말 그대로 서버 문제로 오류가 발생한다. 서버 문제로 발생한 오류로 재시도하면 서버나 DB가 복구되었을 시 성공할 수도 있다. 서버 오류 종류는 다음과 같다
- 500 Internal Server Error : 서버 내부 문제로 오류 발생, 애매하면 500 오류
- 503 Service Unavailabel : 서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음. Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수도 있지만 거의 안쓰고 주로 500 오류로 처리