HTTP 상태코드 : 300번대

오늘은 HTTP 상태코드의 300번대에 대해 알아보겠다.

보통은 리다이렉션을 요청하는 상태코드이다. 

300 번대 결과값이 나오는 요청에는 PRG가 있다. ( PRG란 Post/Redirect/Get 의 앞자리만 따온 것)

---

PRG를 사용해야하는 예시를 하나 들어설명해보겠다. 

만약 POST로 주문 후에 웹 브라우저를 새로 고침한다고 생각해보자. 

새로고침은 다시 요청을 보내고, 중복주문이 될 수 있다.

 

이 상황을 단계로 나타내보자.

1단계 : 주문을 클라이언트에서 요청한다. (POST)
2단계 : 서버는 주문데이터를 디비에 저장한다.
3단계 : 디비에 저장후 서버는 클라이언트에 성공 메시지를 응답한다. 
4단계 : 결과 화면에서 새로고침을 한다.(POST)
5단계 : 또 다시 요청이 클라이언트에서 서버로 들어간다.
6단계 : 서버는 디비에 주문데이터를 저장한다/
7단계 : 서버에서 클라이언트로 성공 메시지를 응답한다.

위와 같은 단계로 결제 사이트가 구성된다면 사용자는 새로고침 할 때마다 결제가 중복될 것이다.

이러한 중복 요청을 막기 위한 일시적인 리다이렉션을 사용해야한다. 

 

 

다음은 PRG를 사용한 예시들이다. 

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

 

PRG를 사용한 예시를 자세하게 단계로 알아보자.

1단계 : 주문을 클라이언트에서 요청한다. (POST)
2단계 : 서버는 주문데이터를 디비에 저장한다.
3단계 : 디비에 저장후 서버는 클라이언트에 성공 메시지를 응답한다.
4단계 : 클라이언트는 자동 리다이렉트로 GET 메서드로 변한다. (GET)
5단계 : 새로고침을 해서 클라이언트에서 서버로 주문데이터 조회를 요청한다.(GET)
6단계 : 서버는 성공 응답을 클라이언트에게 전송한다.

 

위의 사례와 같이 PRG를 사용한 이후의 리다이렉트는

URL이 이미 POST에서 GET으로 리다이렉트된 상태이다.

 

따라서 새로고침을 해도 GET으로 결과 화면만 조회하게 된다.

 

---

PRG를 사용해야 하는 이유를 알게 되었으니 이제 300번대의 HTTP 상태코드에 대해 알아보자.

 

• 302 Found : 리다이렉션시에 GET으로 변함(Maybe)
• 307 Temporary Redirect : 리다이렉션시 무조건 메서드 유지 
• 303 See Other : 리다이렉션 시 메서드 무조건 GET으로 변경

 

 

역사적으로 원래의 302 스펙의 의도는 HTTP 메서드를 유지하는 것이었다. 

하지만 웹 브라우저들이 대부분 GET으로 바꾸어 버리기 때문에 모호한 302대신 307, 303이 등장한 것이다. 

 

303,307을 권장하지만 현실적으로 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용중이다.

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