{ 모든 개발자를 위한 HTTP 웹 기본 지식 } #6 - HTTP 상태코드

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

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

---

1.  HTTP 상태코드 소개

상태코드

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

HTTP 상태 코드는 클라이언트가 서버로 요청을 보내면 요청이 잘 처리가 되어있는지 문제가 있는지 요청의 처리 상태를 응답에서 알려주는 기능이다. 

 

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

클라이언트가 인식할 수 없는 상태코드를 서버가 반환하면 클라이언트는 상위 상태코드로 해석하면 된다. 미래에 새로운 상태 코드가 추가되어도 클라이언트를 변경하지 않아도 된다.

299  ➡️  2xx (Successful)
451  ➡️  4xx (Client Error)
599  ➡️  5xx (Server Error)

---

2. 1xx - 정보

요청이 수신되어 처리 중이다. 거의 사용하지 않는다.

 

---

3. 2xx - 성공

200 OK 

클라이언트의 요청을 성공적으로 처리한 생성코드이다.

201 Created

클라이언트가 요청 성공해서 서버에서 새로운 리소스가 생성하는 상태코드이다. HTTP 헤더에 Location에 생성된 리소스의 URI를 넣어준다. 주로 POST로 201 Created 한다.

 

202 Accepted

요청이 접수되었으나 처리가 완료되지 않은 상태코드이다. 클라이언트입장에서는 요청이 성공했는데 서버 입장에서는 받았다가 1시간 뒤에 배치를 돌려야 프로세스가 요청을 처리한다. 잘 사용하지 않는다. 

 

204 No Content

서버가 요청을 성공적으로 수행했지만 응답 페이로드 본문에 데이터가 없는 상태코드이다. 웹 문서 편집기에 저장 버튼을 누를 때 웹 문서가 POST를 해서 서버로 전달한다. 서버에서 저장한 걸 응답을 보낼 데이터가 없다. 저장 버튼 누르고 계속 편집을 할 거라 결과에 아무 내용이 없는 거다. 

---

4. 3xx - 리다이렉션

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 위치로 자동으로 이동한다. /event 이벤트 페이지에서 /new-event 라는 페이지를 쓰기로 가정하에 설명하면 기존 사용자들은 북마크를 해둘 수 있고 기존의 링크가 여러 군데로 공유가 될 수 있다. 클라이언트가 /event 로 요청하면 서버 입장에서는 /event 를 더이상 쓰지 않으니까 /new-event 를 클라이언트에게 알려줄 때 301 상태코드로 알려준다. 클라이언트는 301 상태코드를 보고 /new-event 를 URL 창에 입력하면 URL 실제 경로 창을 바뀌게 되면서 다시 서버에게 다시 요청을 하면 페이지에 대한 응답 HTML을 클라이언트에게 응답한다. 

 

리다이렉션의 종류

• 영구 리다이렉션 : 특정 리스소의 URI가 영구적으로 이동한다.

/members  ➡️  /users
/event  ➡️  /new-event

 

• 일시 리다이렉션 : 일시적인 변경한다. 주문 완료 후 주문 내역 화면으로 이동한다. 

PRG : Post/Redirect/Get

 

• 특수 리다이렉션 : 결과 대신 캐시를 사용한다. 

 

영구 리다이렉션

영구 리다이렉션은 상태코드가 301, 308이 있다. 리소스의 URI가 영구적으로 이동했다는 거를 알려준다. 그런데 원래의 URI를 더 이상 하면 안된다. 여기서 중요한 거는 검색 엔진들이 원래의 URI로 들어온다. 검색 엔진은 새로운 URI로 써야 한다. 검색 엔진등에서도 변경을 인지할 수 있다. 

 

301 Moved Permanently

클라이언트가 /event 로 내부에 HTTP 바디 메시지에 사용자를 event에 등록하겠다고 POST로 요청하면 서버에서는 /event는 더이상 쓰지 않으니 /new-event 쓰겠다고 클라이언트에게 301 상태 코드를 보낸다. 그러면 클라이언트는 새로운 URI로 경로를 바꾸게 되고 리다이렉트시 요청 메서드가 GET으로 변하고 본문이 제거될 수 있다. 새로운 페이지에서 다시 입력해야 되는 폼 화면이 나와서 사용자는 다시 처음부터 입력해야 된다. 이러한 불편한점이 308 상태코드가 나오게 된거다.

 

308 Permanet Redirect

클라이언트가 /event 로 내부에 HTTP 바디 메시지에 사용자를 event에 등록하겠다고 POST로 요청하면 서버는 /event-new 쓰겠다고 클라이언트에게 308 상태 코드를 보내는데 POST로 유지하면서 HTTP 바디 메시지도 유지된다. 실무에서는 사용하지 않는다. 이유는 /event에서 /new-event로 바뀌면 내부적으로 전달해야 되는 데이터 자체가 바뀌어버린다. POST로 와도 웬만하면 GET으로 돌리는 게 많다. 

 

일시적인 리다이렉션

리소스의 URI가 일시적으로 변경한다. 검색 엔진 등에서 URI을 변경하면 안된다. 실무적에서는 많이 쓰이는 일시적인 리다이렉션이다. 

 

302 Found

리다이렉트 시 요청 메서드가 GET으로 변하고 본문이 제거될 수 있다. 프레임워크나 기술 레벨에서 보면 라이브러리들이 기본값으로 302를 많이 쓰인다. 

 

307 Temporary Redirect

리다이렉트시 요청 메서드와 본문이 유지된다. 요청 메서드를 변경하면 안된다. 

 

303 See Other

리다이렉트 시 요청 메서드가 GET으로 변한다. 

 

PRG (Post/Redirect/Get)

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

 

PRG 사용 전

클라이언트가 /order 에 POST로 상품을 주문한다고 요청을 하면 서버에서는 상품 주문이 들어왔다고 주문 데이터베이스에 저장을 하고 200 상태코드를 보내고 주문완료 페이지를 보낸다. 만약에 실수로 새로 고침을  하면 주문 데이터베이스에서 한 건이 더 들어오게 되고 클라이언트 화면에서 주문 완료 페이지가 된다.  여기서 서버에서는 클라이언트가 실수로 될 사항을 다 막아야 된다. 

 

PRG 사용

클라이언트가 /order 에 POST로 상품을 주문한다고 요청을 하면 서버에서 주문이 들어왔다고 주문 데이터베이스에 저장을 하고 302 상태코드와 /order-result/19 Location 정보를 준다. 클라이언트가 300 상태코드를 보고 리다이렉트를 한다. 주문 데이터를 저장한 거를 쌓는게 아니라 /order-result/19 주문 정보를 조회해서 HTML 화면을 만들고 200 상태 코드를 보낸다. 여기서 클라이언트가 실수로 새로고침을 해도 중복 주문이 아니라 /order-result/19 주문 데이터를 조회하게 된다. 이미 URI이 POST에서 GET으로 리다이렉트가 된 상태이기 때문에 GET으로 된 결과 화면만 조회가 된다. 

 

302, 307, 303 그래서 뭘 써야 하나요?

302 Found : GET으로 변할 수 있음
307 Temporary Redirect : 메서드가 변하면 안됨
303 See Other : GET으로 변경함

처음 302 스펙의 의도는 HTTP 메서드를 유지하려는게 의도였다. 그런데 웹 브라우저들이 대부분 GET으로 바뀌어버려서 모호한 302를 대신 명확하게 307, 303등장하면서 301 대응으로 308도 등장한다. 현실적으로는 307, 303을 권장하지만 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용한다. 자동 리다이렉션시 GET으로 변해도 되면 302를 사용해도 큰 문제가 없다.

 

기타 리다이렉션

300 Multiple Choice

안 씀

 

304 Not Modified

캐시를 목적으로 사용하는데 리소스가 수정되지 않았음을 알려주는 클라이언트에서 서버로 요청한다. 클라이언트가 캐시 만료 다 된거 같아서 서버가 가지고 있는 캐시로 쓰라고 리다이렉트한다. 따라서 클라이언트는 로컬 PC에 저장된 캐시를 재사용한다. 로컬 캐시를 사용해야 하므로 응답에 메시지 바디를 포함하면 안된다.  

---

5. 4xx - 클라이언트 오류

4xx (Client Error)

클라이언트의 요청에 잘못된 문법 등으로 서버가 요청을 수행할 수 없는 상태코드이다. 오류의 원인이 클라이언트에 있다. 중요한거는 클라이언트가 이미 잘못된 요청을 데이터를 보내고 있기 때문에 똑같은 재시도가 실패한다. 

 

400 Bad Request

클라이언트가 잘못된 요청을 해서 서버가 요청을 할 수 없는 상태코드이다. 주로 요청 구문, 메시지 등으로 오류가 난다. 클라이언트는 요청 내용을 다시 검토하고 다시 보내야 한다. 요청 파라미터나 잘못되었거나 문자를 보내야 되는 숫자를 보낸 API 스펙이 맞지 않을 때 주로 나타난다.  

 

401 Unauthorized 

클라이언트가 해당 리소스에 대한 인증이 필요하다. 오류 발생시 응답에 WWW-Authenticate라는 헤더와 함께 인증하는 방법을 설명을 해줘야 된다. 

인증(Authentication) : 본인이 누구인지 확인하는 과정이다. 
인가(Authorization) : 특정 리소스에 접근할 수 있는 권한이 있는 사람만 볼 수 있는 권한 부여이다.
오류 메시지가 Unauthorized이지만 인증 자체가 안된다는 뜻이다. 

 

403 Forbidden

클라이언트가 보낸 요청을 서버가 이해했지만 승인을 거부하는 상태코드이다. 주로 인증 자격 증명은 있지만 접근 권한이 없을 때 볼 수 있다. 어드민 등급이 아닌 사용자가 다른 리소스로 로그인은 했지만 어드민 등급의 리소스에 접근할 때 오류가 나타난다.

 

404 Not Found

요청 리소스를 찾을 수 없는 상태코드이다. 리소스 자체가 없는데 서버에게 보낸거다. 클라이언트가 권한이 부족한 리소스에 접근할 때, 해당 리소스를 숨기고 싶을 때 요청한다.

---

6. 5xx - 서버 오류

5xx (Server Error)

서버 문제로 오류 발생한다. 서버에 문제가 있기 때문에 재시도 하면 복구하거나 성공할 수 있다.

 

500 Internal Server Error

서버 내부 문제로 오류 발생한 상태코드이다. 애매한 오류는 500 상태코드이다.

 

503 Service Unavaliable

서버가 일시적인 과부하 되거나 예정된 작업으로 잠시 요청을 처리할 수 없다. Retry-After 헤더로 얼마 뒤에 복구되는지 예상 시간을 볼 수 있다.