HTTP Status Code(상태 코드)

2023.06.23 - [Http] - HTTP

HTTP

HTTP 상태 코드에 대해서 공부하기 이전에, HTTP 에 대해 공부하고자 한다면 위의 글을 읽어보길 바란다.

---

HTTP 상태 코드란?

→ 클라이언트가 보낸 요청의 처리 상태를 응답에서 알려주는 기능

흔히, 우리가 잘못된 접근이나 페이지가 삭제된 URL을 눌렀을 때, 404와 같은 숫자 코드들을 본 경험이 있을 것이다.

그런것들이 사용자에게 보여주는 HTTP 상태 코드라고 할 수 있다.

 

그렇다면, 그 많은 상태 코드들을 어떻게 구분할 수 있을까?

큰 틀을 나누어서 설명해보겠다.

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

한마디로, 우리가 잘 모르는 상태 코드가 나타나더라도 맨 앞 숫자로 크게 구분이 가능하다는 말이다.

예를 들어, 479 → 클라이언트의 오류 , 588 → 서버의 오류 와 같이 말이다.

---

최근에는 인터넷 속도도 빠르고해서 1XX 와 같은 상태 코드는 거의 사용되지 않는다. 

때문에, 2XX~ 5XX 까지만 더 자세히 알아보도록 하겠다.

 

2XX ( Successful )

→ 클라이언트의 요청을 성공적으로 처리

 

• 200 OK
• 201 Created
• 202 Accepted
• 204 No Content

해당 코드들이 200대에서 주로 사용되는 코드들이다.

해당 코드는 HTTP 응답 헤더에 포함되어 있는데 이 전의 글에서도 본 적이 있을 것이다.

 

200 OK 는 요청 성공

201 Created는 요청에 성공해서 새로운 리소스가 생성

그림에서 알 수 있듯이, 생성된 리소스는 Location 헤더 필드를 통해 나타낸다.

 

202 Accepted는 요청이 접수되었으나 처리가 완료되지 않았다는 것을 의미한다.

→ 배치 처리 등에 사용된다.

204 No Content는 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음을 의미한다.

→ 예를 들어, SAVE 버튼을 누르면 버튼의 결과로 아무 내용이 없어도 된다. 또한, 눌러도 같은 화면을 유지해야 함.

---

3XX ( Redirection )

→ 요청을 완료하기 위해 유저 에이전트(웹 브라우저)의 추가 조치 필요

 

• 300 Multiple Choices ( 사용 X )
• 301 Moved Permanently ( 영구 리다이렉션 )
• 302 Found ( 일시적인 리다이렉션 )
• 303 See Other ( 일시적인 리다이렉션 )
• 304 Not Modified ( 특수 리다이렉션 )
• 307 Temporary Redirect ( 일시적인 리다이렉션 )
• 308 Permanent Redirect ( 영구 리다이렉션 )

리다이렉션

→ 웹 브라우저(사용자)는 3XX 응답의 결과에 Location 헤더 필드가 있으면, Location에 있는 해당 위치로 자동 이동

예를 들어, event 라는 URL의 홈페이지가 있었는데 이름을 new-event로 바꾼다면 어떻게 될까? 페이지가 없다고 뜰까?

그럴때 사용하는 게 리다이렉션이다.

자동 리다이렉션을 통해 웹 브라우저는 event로 요청을 보냈지만, 301 상태 코드와 함께 Location 정보가 왔기 때문에 Location 필드에 있는 URL로 자동으로 옮겨가게 됨. ( 사용자는 모른다. ) 

 

리다이렉션의 종류

• 영구 리다이렉션
  • 예) /event → /new-event
• 일시 리다이렉션 → 일시적인 변경 
  • 주문 완료 후 주문 내역 화면으로 이동
  • PRG(Post/Redirect/Get) → Post방식으로 데이터 처리를 요청했다가 그 창을 새로고침하게 되면 Post를 통한 행위가 계속해서 반복됨 → 이를 방지하기 위해, Post 데이터 처리를 한 뒤 응답 헤더에 Redirect를 통해 Get방식으로 해당 페이지를 다시 요청하게끔 만듬 → 이러면 새로고침을 해도 Get 요청만 반복되므로 문제 해결됨 
• 특수 리다이렉션
  • 결과 대신 캐시를 사용

---

영구 리다이렉션

→ 301, 308이 해당

리소스의 URI가 영구적으로 이동할 때 사용된다. 때문에, 원래의 URL을 사용하지 않음.

 

301 Moved Permanently

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

308 Permanent Redirect

→ 301과 기능은 같으나, 리다이렉트시 요청 메서드와 본문을 유지(처음 POST를 보내면 리다이렉트도 POST 유지)

 

일시적인 리다이렉션

→ 302, 307, 303이 해당 + PRG(Post/Redirect/Get)

리소의 URI가 일시적으로 변경될 때 이용된다. 때문에, 검색 엔진 등에서 URL을 변경하면 안된다.

 

302 Found

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

 

307 Temporary Redirect

→ 302와 기능은 같으나, 리다이렉트시 요청 메서드와 본문 유지( 요청 메서드를 변경하면 안된다. MUST NOT )

 

303 See Other

→ 302와 기능은 같으나, 리다이렉트시 요청 메서드가 GET으로 변경 ( 본문 제거 X )

 

307, 303을 사용하는 것을 권장하지만 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용하고 있다.

때문에, 자동 리다이렉션 시에 GET으로 변해도 된다면 302를 그냥 사용해도 큰 문제가 없다.

 

 

기타 리다이렉션

→ 304 가 해당

 

304 Not Modified

캐시를 목적으로 사용한다.

이는 말그대로 클라이언트에게 리소스가 수정되지 않았음을 알려준다.

따라서 클라이언트는 로컬 PC에 저장된 캐시를 재사용하게 된다. → 캐시로 리다이렉트

304 응답은 응답에 메세지 바디를 포함하면 안된다. → 로컬 캐시를 사용해야함

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

---

4XX ( Client Error )

→ 클라이언트의 오류

 

• 400 Bad Request ( 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음)
• 401 Unauthorized ( 클라이언트가 해당 리소스에 대한 인증이 필요함 )
  • 401 오류 발생시 응답에 WWW-Authenticate 헤더와 함께 인증 방법 설명
• 403 Forbidden ( 서버가 요청을 이해했지만 승인을 거부함 )
  • 주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우
• 404 Not Found ( 요청 리소스를 찾을 수 없음 )

 

오류의 원인이 클라이언트에게 있다.

클라이언트는 잘못된 요청을 계속 보내기때문에 재시도를 반복해도 계속 실패하게 된다.

---

5XX ( Server Error )

→ 서버 오류

 

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

 

오류의 원인이 서버에게 있다. 때문에, 재시도를 하면 성공을 할 수도 있다. (복구가 되거나 한다면)

 

개발자에게 있어서 500대 오류는 최대한 안나도록 해야 할 것을 명심하자!!

---

정리

 

이번 시간에는 HTTP 상태 코드들에 대해서 알아보았다.

자세히 알아볼 부분이라면, 리다이렉션이 있는 3XX 부분이 좀 어려울 수 있으나 이는 나중에 스프링 MVC에서도 사용되기 때문에 꾸준히 복습해야 할 것이다.

또한, 서버에서 오류를 발생시키는 일(5XX 오류)은 최대한 없도록 빈틈없이 개발하는 것을 목표로 하자!

다음시간에는 HTTP Header에 대해서 더 자세히 알아보도록 하겠다.