[Network] #21 HTTP 상태 코드

2025-01-01 6 분 소요

[혼자 공부하는 네트워크↗️], 컴퓨터 네트워킹: 하향식 접근 (제8판), 김영한 HTTP 웹 기본 지식을 바탕으로 정리한 글입니다.

1. 상태 코드란?

상태 코드란, 클라이언트가 보낸 요청의 처리 상태를 응답해서 알려주는 기능이다.

상태 코드의 종류는 백의 자리 수를 기준으로 유형을 구분한다.

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

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

클라이언트가 인식할 수 없는 상태코드를 서버가 반환하면?
클라이언트는 상위 상태코드로 해석해서 처리한다.
미래에 새로운 상태 코드가 추가되어도 클라이언트를 변경하지 않아도 된다.
e.g.,
- 299 ??? -> 2xx (Successful)
- 451 ??? -> 4xx (Client Error)
- 599 ??? -> 5xx (Server Error)

2. 200번대 - 성공

클라이언트의 요청이 성공했음을 의미한다.

2.1 200 (OK)

e.g., “http://example.com/images/a.png”로 GET 요청을 성공적으로 보낸 경우, 상태코드 200 (OK)를 응답한다.

아래와 같이 요청한 리소스를 메시지 본문을 통해서 응답 받을 수 있다.

2.2 201 (Created)

POST 요청으로 서버에 새로운 리소스를 생성한 경우, 상태 코드 201 (Created)를 응답한다.

이때, Location 헤더를 통해 생성된 리소스의 위치를 명시한다.

2.3 202 (Accepted)

요청을 잘 받았으나 아직 요청한 작업을 끝내지 않았을 경우, 상태코드 202 (Accepted)를 응답한다.

요청 결과를 곧바로 응답하기 어려운 경우 혹은, 배치 처리 같은 곳에서 사용한다.
잘 사용하지는 않는다.
e.g.,
요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리
- 작업 시간이 긴 대용량 파일 업로드 작업 등

2.4 204 (No Content)

요청을 잘 받았고, 응답 페이로드 본문에 보낼 데이터가 없을 경우, 상태코드 204 (No Content)를 응답한다.

e.g., 웹 문서 편집기에서 save 버튼
save 버튼의 결과로 아무 내용이 없어도 된다.
save 버튼을 눌러도 같은 화면을 유지해야 한다.
결과 내용이 없어도 204 메시지(2xx)만으로 성공을 인식할 수 있다.

3. 300번대 - 리다이렉션

3.1 리다이렉션이란?

리다이렉션(redireaction)이란, 요청을 완수하기 위한 유저 에이전트(주로 웹 브라우저)의 추가적인 조치가 필요한 상태를 의미한다.

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

리다이렉트 이해

클라이언트가 /event로 초기 요청을 보냄
서버는 301 응답(영구 이동)을 보내며, /event에 있는 리소스를 /new-event로 이동한다고 알림
브라우저는 301 응답을 받고 자동으로 /new-event로 리다이렉트
클라이언트가 /new-event에 대한 새로운 요청을 보냄
서버는 /new-event에 대한 자원을 응답

리다이렉션 종류

영구적인 리다이렉션
- 특정 리소스의 URI가 영구적으로 이동
- e.g.,
  - /members -> /users
  - /event -> /new-event
일시적인 리다이렉션
- 일시적인 변경
- PRG: Post/Redirect/Get
- e.g.,
  - 주문 완료 후 주문 내역 화면으로 이동
특수 리다이렉션
- 결과 대신 캐시를 사용

3.2 영구적인 리다이렉션

리소스가 완전히 새로운 곳으로 이동하여 요청을 보내야하는 경로가 영구적으로 재지정 되었을 때, 영구적인 리다이렉션(permanent redirection)이라고 한다.

리소스의 URI가 영구적으로 이동 → 원래의 URL 사용X
검색 엔진 등에서도 변경 인지

| 상태 코드 | 이유 구문 | 설명 | | :——-: | :—————-: | :—————————————————————————————————————————–: | | 301 | Moved Permanently | - 재 요청 메서드가 변경될 수 있다.
- 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다. (MAY)
- 대부분 GET으로 변한다고 한다. (많이 사용하기 때문에 스펙 자체를 변경) | | 308 | Permanent Redirect | - 재 요청 메서드가 변경되지 않는다.
- 리다이렉트시 요청 메서드와 본문이 유지된다. (처음 POST를 보내면 리다이렉트도 POST 유지) |

💡 실무에서는 URI 변경 시 데이터가 다르게 처리되는 경우가 많기 때문에, 리다이렉션을 처리할 때 GET 요청을 사용하는 것이 일반적이다. 즉 대다수 301을 사용한다.

(하지만, 301도 많이 사용하지 않는다. 일시적인 리다이렉션을 더 많이 사용한다고 한다.)

3.3 일시적인 리다이렉션

리소스의 위치가 임시로 변경되었거나 임시로 사용할 URL이 필요한 경우에 주로 사용된다.

리소스의 URI가 일시적으로 변경되므로, 검색 엔진 등에서 URL을 변경하면 안된다.
어떤 URL에 대해 일시적인 리다이렉션 관련 상태 코드를 응답 받았다면 여전히 요청을 보낸 URL은 기억한다.

| 상태 코드 | 이유 구문 | 설명 | | :——-: | :—————-: | :——————————————————————————————: | | 302 | Found | 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다. (대부분 다 GET으로 변경) | | 303 | See Other | 리다이렉트시 요청 메서드가 GET으로 변경된다. | | 307 | Temporary Redirect | 리다이렉트시 요청 메서드와 본문이 변경되지 않는다. (요청 메서드를 변경하면 안된다. MUST NOT) |

💡 실무에서는 아직도 많이 302를 사용한다고 한다. 큰 문제가 없기 때문

3.3.1 PRG: Post/Redirect/Get⭐

PRG (Post/Redirect/Get)는 POST 요청 후에 새로 고침으로 인한 중복 요청을 방지하는 패턴이다.

예를 들어, 주문 처리를 POST로 하면 새로 고침 시 중복된 주문이 발생할 수 있는데, PRG 패턴을 사용하면 이를 방지할 수 있다.

PRG 사용 전

POST 요청: 주문 요청
주문 데이터 저장
응답 (200 OK)
결과 화면에서 새로 고침
다시 요청 (POST)
주문 데이터 저장 (중복된 데이터 저장)
응답 (중복 주문 발생)

PRG 사용 후 (Post -> Redirect -> Get)

POST 요청: 주문 요청
주문 데이터 저장
응답: 결과 화면 표시 응답 (302/303 Found)
GET으로 리다이렉트
GET 요청
주문 데이터 조회
응답: 결과 화면 표시 (중복되지 않음)
결과 화면에서 새로 고침해도 결과 화면만 다시 요청 (5번으로 이동)

💡 POST로 주문 후에 URL이 이미 POST -> GET으로 리다이렉트 되므로, 새로 고침 해도 GET으로 결과 화면만 조회하여 중복 주문을 방지할 수 있다.

3.3.2 그래서 뭘 써야 할까?

상태 코드	설명
302 Found	기본적으로 `GET`으로 변경될 수 있음. (브라우저의 동작에 따라 다를 수 있지만, 거의 변함)
303 See Other	리다이렉트 시 요청 메서드는 강제로 `GET`으로 변경됨.
307 Temporary Redirect	리다이렉트 시 요청 메서드와 본문이 그대로 유지됨. 메서드를 변경하면 안 됨.

역사

302 Found의 원래 의도는 HTTP 메서드를 유지하는 것이었지만, 브라우저들이 대부분 GET으로 변경하므로 모호한 동작이 발생했다.
이에 따라 명확한 동작을 위해 303과 307이 등장하였다.

현실

307, 303을 사용하는 것이 바람직하지만, 많은 애플리케이션과 라이브러리들이 여전히 302를 기본값으로 사용하고 있다.
자동 리다이렉션 시 GET으로 변해도 괜찮다면 302를 사용해도 큰 문제는 없다.

3.3.3 기타 리다이렉션 코드

300 Multiple Choices
- 사용되지 않는다.
304 Not Modified
- 캐시 관련 리다이렉션에 사용된다.
- 클라이언트는 로컬 캐시에서 리소스를 가져와서 요청을 다시 보내지 않게 된다.
- 304 응답은 응답에 메시지 바디를 포함하지 않는다. 클라이언트는 캐시된 데이터를 사용해야 한다.
- 조건부 GET, HEAD 요청 시 사용한다.

4. 400번대 - 클라이언트 오류

클라이언트의 요청에 잘못된 문법등으로 서버가 요청을 수행할 수 없음을 알려주는 상태 코드이다.

오류의 원인이 클라이언트에 있다!
⭐ 클라이언트가 이미 잘못된 요청, 데이터를 보내고 있기 때문에, 똑같은 재시도가 실패한다.

4.1 400 (Bad Request)

클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음을 알려 주는 상태 코드

요청 구문, 메시지 등등 오류
클라이언트는 요청 내용을 다시 검토하고, 보내야한다.
e.g., 요청 파라미터가 잘못되거나, API 스펙이 맞지 않을 때

4.2 401 (Unauthorized)

클라이언트가 해당 리소스에 대한 인증이 필요할 경우 서버는 401 (Unauthorized)을 응답

인증(Authentication)이 되지 않았음을 알려주는 상태 코드이다.
서버가 상태 코드 401로 응답할 때는 반드시 WWW-Authenticate 라는 헤더를 통해 인증 방법을 알려줘야한다.

인증(Authentication) 여부와 권한 부여(Authorization) 여부

인증 (Authentication)
- 본인이 누구인지 증명하는 것
- e.g., 로그인
인가 (Authorization)
- 권한부여
- ADMIN 권한처럼 특정 리소스에 접근할 수 있는 권한, 인증이 있어야 인가가 있음

4.3 403 (Forbidden)

클라이언트 권한이 충분하지 않다면 상태코드 403 (Forbidden)를 응답

서버가 요청을 이해했지만 승인은 거부
주로 인증 자격 증명은 있지만, 접근 권한이 불충분한 경우
e.g., 어드민 등급이 아닌 사용자가 로그인은 했지만, 어드민 등급의 리소스에 접근하는 경우

4.4 404 (NotFound)

접근하고자 하는 리소스가 존재하지 않음을 알리는 상태 코드

존재하지만 공개하지 않는 리소스에 대해 404(NotFound)를 응답하는 경우도 있다.

4.5 405 (Method Not Allowed)

구현되지 않는 메서드로 요청을 보낼 경우 싱태 코드 405 (Method Not Allowed)를 응답

5. 500번대 - 서버 오류

클라이언트가 올바르게 요청을 보냈을지라도 서버 문제로 오류 발생

서버 잘못 (서버 폭파, 서버 오류 등으로 응답을 줄 수 없는 상태)
서버에 문제가 있기 때문에 재시도 하면 성공할 수도 있다.(복구가 되거나 등등)

5.1 500 (Internal Server Error)

서버 내부 문제로 인해 요청을 처리할 수 없음을 알리는 상태 코드

상태 코드 500은 서버 에러를 통칭한다.
애매하면 500 오류!

5.2 502 (Bad Gateway)

클라이언트와 서버 사이에 위치한 중간 서버의 통신 오류를 나타내는 상태 코드

중간 서버가 유효하지 않거나 잘못 된 응답을 받을 때 볼 수 있는 상태

5.3 503 (Service Unavailable)

현재 서비스를 일시적으로 이용할 수 없음을 알리는 상태 코드

서버가 과부하 상태에 있거나 일시적인 점검 상태일 때 볼 수 있는 상태
Retry-After 헤더 필드로 얼마뒤에 복구되는지 보낼 수도 있다.

박시은