[HTTP] HTTP 상태코드

100 (continue)
현재까지의 진행상황이 문제 없으니 다음 요청을 이어서 보내도 된다 라는 뜻.
-> 만약 클라이언트의 작업이 완료되었다면 이 응답은 무시해도 됨.
101 (Switching Protocols)
클라이언트가 헤더를 통해 요청한 것에 따라 서버가 프로토콜을 바꾼다는 것을 알려주는 응답 코드Websocker 프로토콜 전환 시에 사용.

102 (Processing(WebDAV))
이 응답은 서버가 요청을 수신하였으며 이를 처리하고 있는중이라는 응답.

103 (Early Hints)
서버가 응답을 준비하는 동안에 클라이언트가 자원을 미리 읽어들일 수 있도록 Link 헤더와 함께 사용. -> 현재는 크롬만 지원

2xx (Successful)

200 OK : 요청 성공
201 Created : 요청을 성공해서 새로운 리소스가 생성됨 → 새로 생성된 uri는 header 필드의 location에서 식별
202 Accepted : 요청이 접수되었으나 처리가 완료되지 않았음 → 잘 사용하지 않음. ex) 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리함
204 No Content : 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음. ex) 웹 문서 편집기의 save 버튼 → 결과로 아무 내용이 없어도 된다.

3xx (Redirection)

요청을 완료하기 위해 유저 에이전트의 추가 조치 필요

300 Multiple Choices → 거의 안씀
요청에 대해서 하나 이상의 응답이 가능. 클라이언트는 그 여러개의 응답 중 반드시 한개를 선택.
301 Moved Permanently
302 Found
303 See Other
304 Not Modified
307 Temporary Redirect
308 Permanent Redirec

리다이렉션 이란?

웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면, Location 위치로 자동 이동(리다이렉트)
-> 기존의 url이 바뀌고 기존의 url로 접속했을 때, 서버가 3xx와 함께 새로운 url을 Location으로 줌.
그럼 다시 Location의 url로 자동 리다이렉트 함.

리다이렉션의 종류

영구 리다이렉션
특정 리소스의 URI가 영구적으로 이동
ex) /members -> /users 등으로 아예 바뀌는 것.

301 Moved Permanently
리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음
예전의 uri로 데이터를 POST로 요청했을 때 새주소로 리다이렉트 되면서 GET을 사용해, 원래있던 본문이 사라질 수 있음.
308 Permanent Redirect
301과 기능은 같음, 단 리다이렉트시 요청 메서드와 본문 유지
(처음 POST를 보내면 리다이렉트도 POST 사용)
→ 하지만 실제로는 이렇게 사용안함 (보통 url이 바뀌는 경우 데이터의 url등도 다 바뀌기 때문에 GET으로 보내는 경우가 많다)

임시 리다이렉션
리소스의 uri가 일시적으로 변경, 따라서 검색 엔진 등에서 url을 변경하면 안됨.

302 Found 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음 (may)
307 Temporary Redirect 302와 기능 같음. 리다이렉트시 요청 메서드와 본문 유지 (변경X) (must not)
303 See Other 302와 기능 같음. 리다이렉트시 요청 메서드가 GET으로 변경

→ 302와 303의 다른점은 302는 명확하게 GET으로 모두 바꾼다가 아니지만 303은 맞음.

PRG : Post/Redirect/Get : 일시적인 리다이렉션 예시
- 만약 POST로 주문 후 웹 브라우저를 새로고침 하면 (새로고침은 다시 요청이므로) 중복 주문이 될 수 있다.
- 이것을 해결하기 위해 POST로 주문 후에 주문 결과 화면을 GET 메서드로 리다이렉트
- 새로고침은 마지막 요청을 다시 하는 것이므로 마지막 요청인 결과화면 출력(GET)을 다시 요청하므로 중복 주문 방지

⇒ 이렇게 클라이언트에서 처리해주면 서버관리가 편해지고 안정성이 높아진다.

특수 리다이렉션

300 Multiple Choices : 안쓴다.
304 Not Modified
캐시를 목적으로 사용, 클라이언트에게 리소스가 수정되이 않았음을 알려준다. 따라서 로컬pc에 저장된 캐시를 재사용한다. (클라이언트가 “데이터 줘” 했을 때 서버가 “너가 저번에 받아갔던 데이터 그대로니까 그거 써”한다는 소리)
→ 로컬 캐시를 사용하므로 304응답은 메세지 바디를 포함하면 안된다.

4xx (Client Error)

오류의 원인이 클라이언트에 있음

→ 클라리언트가 요청 자체를 잘못 보낸 것. 똑같이 재시도 해도 실패함.

400 Bad Request
클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음 (파라미터, api등을 잘못 보낼때)
401 Unzuthorized
인증 되지 않음, 오류 발생 시 응답에 WWW-authenticate 헤더와 함께 인증 방법을 설명
참고
- 인증(Authentication) : 본인이 누구인지 확인, (로그인)
- 인가(Authorization) : 권한부여 (ADMIN 권한처럼 특정 리소스에 접근할 수 있는 권한, 인증이 있어야 인가가 있음)
- 오류 메세지가 Unauthorized이지만 인증 되지 않음 (이름이 아쉬움)
403 Forbidden
서버가 요청을 이해했지만 승인을 거부함, 보통 인증은 되었지만 권한(인가)이 없을 때.
404 Not Found
요청 리소스가 서버에 없음, 또는 클라이언트가 권한이 부족한 리소스에 접할 때 해당 리소스를 숨기고 싶을 때

5xx (Server Error)

서버 문제로 오류 발생,

→ 서버문제가 해결될 경우 같은 요청을 시도하면 나중에 성공할수도 있음.

500 Internal Server Error
서버 내부 문제로 오류 발생, 애매하면 500 오류
503 Service Unavailable
서버가 일시적인 과부하 또는 예정된 작업으로 잠시 요청을 처리할 수 없음. (Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수도 있음.)