김영한님의 모든 개발자를 위한 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)
- 308 Permanent Redirect
- 301과 기능은 같지만 요청 메서드와 본문 유지 (처음 POST로 보내면 리다이렉트도 POST도 유지)
* 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
요청 리소스를 찾을 수 없음
- 요청 리소스가 서버에 없음
- 또는 해당 리소스를 숨기고 싶을 때
5xx (Server Error)
서버 오류
- 서버 문제로 오류가 발생
- 4xx와 다르게 재시도하면 성공할 수도 있음 (서버가 복구되면)
* 참고 : 결제 요청 시 고객의 잔액이 부족하면 5xx 에러를 내면 안 된다.
500 Internal Server Error
서버 문제로 오류 발생, 애매하면 모두 500 에러
503 Service Unavailable
서비스 이용 불가
- 서버가 과부하 되었거나, 배포 작업 등으로 이용 못할 경우 사용
- Retry-After 헤더 필드로 언제 복구되는지 보낼 수도 있음.
'교육 및 인강 > 모든 개발자를 위한 HTTP 웹 기본 지식 - 김영한' 카테고리의 다른 글
HTTP 헤더2 - 캐시와 조건부 요청 (0) | 2021.12.13 |
---|---|
HTTP 헤더1 - 일반 헤더 (0) | 2021.12.13 |
HTTP 메서드 활용 (0) | 2021.12.10 |
HTTP 메서드 (0) | 2021.12.09 |
HTTP 기본 (0) | 2021.12.09 |