06. HTTP 웹 기본 지식 - HTTP 상태코드 소개

HTTP 상태코드란?

클라이언트가 보낸 요청의 처리가 상태를 응답해주는 기능

 

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

 

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

  - 200 OK : 결과를 정상적으로 처리 했다.

  - 201 Created : 요청 성공해서 새로운 리소스가 생성됨 ( post 요청에 대한 응답으로 Location 에 생성된 리소스의 url를 삽입 )

  - 202 Accepted : 요청이 접수되었으나 처리가 완료되지 않았음 -> 배치 처리 같은곳에서 사용 (요청을 하고 나중에 한번에 처리하는 것)  

  - 204 No Content : 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없을 때 2xx 코드로 성공만을 인식한다.

 

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

리다이렉션이 뭘까?

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

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

  - 300 Multiple Choices ( 거의 사용되지 않음 ) 

  - 301 Moved Permanaently -> Location: /new-event 를 넣어줘서 새로운 위치로 이동한다

    예) 클라이언트 요청 -> 서버(이 url은 301네 Location : /new-event url로 리다이렉션 ㄱ)

                                                              -> 클라이언트 (ㅇㅋ 다시 요청) -> 서버( 200 OK )

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

        301(Moved Permanaently), 308 ( Permanaent Redirect ) 원래의 URL을 사용하지 않음, 검색 엔진 등에서도 변경 인지.

        301은 리다이렉트시 요청 메서드가 GET으로 변하고 본문이 제거될 수 있음

        308은 리다이렉트시 요청 메서드와 본문 유지 ( 301이 본문을 제거하는 문제를 해결 해줌 ) -> 하지만 보통 301을 쓴다

 

     - 일시 리다이렉션 - 일시적인 변경 -> 주문 완료 후 주문 내역화면으로 이동

        일시적으로 변경되기 때문에 검색 엔진 등에서 URL을 변경하면 안된다. 

        302 (Found): 리다이렉트시 요청 메서드가 대부분 GET으로 변하고 본문이 제거될 수 있음

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

        303 (See Other): 리다이렉트시 요청 메서드가 GET으로 변경

 

일시적 리다이렉션은 어디서 사용될까?

POST로 주문을 했을 때 브라우저가 새로고침이 되면 POST가 한번 더 요청 될 수 있다. -> 중복 주문이 될 수 있다.

--> POST로 주문후에 주문 결과 화면을 GET 메서드로 리다이렉트 하게 되면 새로고침해도 결과화면을 GET으로 조회한다.

 

비슷한 기능이 많은데 어떤걸 써야할까?

302 HTTP 스펙의 의도는 HTTP 메서드를 유지하는 것이나 브라우저들이 GET으로 바꿔버리고 일부는 다르게 동작하기 때문에 명확한 307, 303이 등장했지만 현실적으로 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용하기 때문에 GET 메서드가 변하는게 상관이 없으면 302를 사용해도 문제가 없다.

 

     - 특수 리다이렉션 - 결과 대신 캐시를 사용 -> 클라이언트의 캐시가 만료되어 서버에게 캐시 확인 요청 해줌

         - 304 Not Modified 

         캐시를 목적으로 사용

         클라이언트에게 리소스가 수정되지 않았음을 알려준다. 클라이언트는 로컬PC에 저장된 캐시를 재사용! -> 캐시로 리다이렉트 한다.

         로컬 캐시를 사용하기 때문에 응답 바디를 포함하면 안된다.

         조건부 GET, HEAD 요청시 사용한다.

     예를들어

     클라이언트가 자신의 파일의 수정정보를 주면서 변경되었는지 확인하려고 서버에게 요청한다.

     서버는 해당 파일의 수정정보가 변경되지 않았음을 감지하고 304 코드를 보내서 클라이언트가 해당 파일을 그대로 사용할 수 있게 한다.

 

 

 

 

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

중요한것은 클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에 재시도 해도 실패

요청 구문, 메시지 등등 오류이기 때문에 요청 내용 검토하고 보내야 한다. 서버에서 클라이언트의 실수를 알수 있도록 조건검사를 철저하게 해주어야 한다.

 

- 401 Unauthorized

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

이 오류가 발생시 응답에 WWW_Authenticate 헤더와 함께 인증 방법을 설명해주어야 합니다.

 

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

인가(Authorization) : 권한부여 (ADMIN 권한처럼 특정 리소스에 접근할 수 있는 권한, 인증이 있어야 인가가 있음)

 

-> 오류 메시지가 Unauthorized 이지만 인증 되지 않음이라고 이해하면 됩니다!

 

- 403 Forbiden

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

주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우

 

- 404 Not Found

요청 리소스를 찾을 수 없음

해당 요청 리소스가 서버에 없거나 클라이언트가 권한이 부족한 리소스에 접근할 때 해당 리소스를 숨기고 싶을 때

 

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

서버 오류

서버 문제로 오류 발생

 

500 Internal Server Error

서버 문제로 오류 발생, 애매하면 500 오류

서버에서 임의로 생성하면 좋지 못하다,, 왜냐하면 서버에서 진짜 문제가 있을 때 났다고 모니터링해야 한다.

 

503 Service Unavailable

서비스 이용 불가

서버가 일시적인 과부화, 예정된 작업으로 잠시 요청을 처리할 수 없음

얼마뒤에 복구되는지 보낼 수도 있음 

 

클라이언트가 인식할 수 없는 상태코드를 서버가 반환한다면 어떻게 될까?

클라이언트는 상위 상태코드로 해석해서 처리하면 됩니다. 예를 들어 233 이라는 상태모드가 온다해도 2xx 이므로 요청이 정상 처리 되었구나 하면 됩니다!