21. 모든 개발자를 위한 HTTP 웹 기본 지식 - [HTTP 상태코드] - 3xx - 리다이렉션 2

⚠️ 일시적인 리다이렉션 - 302, 307, 303

리소스의 URI가 일시적으로 변경

• 검색 엔진 등에서 URL을 변경하면 안 됨
• 302, 307, 303의 기능은 동일
• 실무적에서 많이 쓰이는 일시적인 리다이렉션이다.

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

        프레임워크나 기술 레벨에서 보면 라이브러리들이 기본값으로 302를 많이 쓰인다.

 

2) 307 Temporary Redirect

         리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안 됨=MUST NOT)

 

3) 303 See Other

       리다이렉트시 요청 메서드가 GET으로 변경(MUST)

---

🧙🏻‍♂️ PRG: Post/Redirect/Get

POST로 주문 후에 새로 고침으로 인한 중복 주문이 될 수 있다. 이러한 경우, PRG를 사용한다.

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

(참고) 새로고침(Refresh)은 마지막에 요청한 request를 재요청하도록 정의하고 구현됨

 

 

🚶🏻RPG 사용 전

1. 클라이언트가 /order로 마우스 1개를 POST로 주문 요청한다.
2. 서버는 주문 데이터(마우스 1개)를 DB에 저장한다.
3. 서버가 200 코드와 주문완료 html 리소스(주문완료 페이지)를 클라이언트에 응답한다.
4. 만약에 실수로 결과 화면을 새로고침 하면 마지막 POST 요청을 새로고침 하게 된다.
5. 그럼 주문 데이터베이스에서 한 건이 더 들어오게 되고 클라이언트 화면은 주문 완료 페이지가 된다. (클라이언트는 마우스 1개를  POST로 중복 주문 요청을 한 것.)
6. 서버는 주문 데이터(마우스 1개)를 DB에 중복 저장한다.
7. 서버가 200 코드와 주문완료 html 리소스를 클라이언트에 응답한다.
   > 여기서 서버에서는 "잘못된 주문코드번호입니다"같은 응답으로 클라이언트 실수(중복 주문)를 방지해야 함

 

🏃🏻 PRG 사용 후

• > 클라이언트차원에서 중복 주문 방지: PRG 이후 리다이렉트
• URL이 POST->GET으로 리다이렉트 되어 새 로고침해도 GET으로 결과 화면만 조회

1. 클라이언트가 /order로 마우스 1개를 POST로 주문 요청한다.
2. 서버는 주문 데이터(마우스 1개)를 DB에 저장한다.
3. 서버가 302 코드와 Location에 /order-result/19를 담아 클라이언트에 응답한다.
4. 웹 브라우저에서 302 코드를 보고 /order-result/19로 자동 리다이렉트한다.
5. 클라이언트가 실수로 새 로고침하여 GET으로 /order-result/19에 주문 결과화면을 요청한다.
6. 서버는 DB에 중복 데이터를 쌓지 않고 19번 주문의 주문데이터를 조회한다.
7. 서버가 200 코드와 주문완료 html 리소스를 클라이언트에 응답한다.
8. 결과 화면에서 새로고침을 하면 마지막 GET요청을 새로 고침 한다.

---

🧹 302, 303, 307 정리

1. 302 - 메서드가 GET으로 변할 수 있음
2. 307 - 메서드가 변하면 안 됨
3. 303 - 메서드가 GET으로 변경됨

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

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

---

🎸 기타 리다이렉션 - 300, 304

1) 300 Multiple Choices - 사용 X

 

2) 304 Not Modified

• 캐시 목적으로 사용
• 클라이언트에게 리소스가 수정되지 않았음을 알려줌 -> 클라이언트는 로컬 PC에 저장된 캐시 재사용(캐시로 리다이렉트)
• 로컬 캐시를 사용해야 하므로 응답에 메시지 바디를 포함하면 안 됨
• 조건부 GET, HEAD 요청 시 사용

---

 

🙋🏻‍♂️ Q&A

Q. 브라우저에서 POST 요청을 서버에 하고 클라이언트는 아직 302 응답을 받지 못한 상황에서 새로고침을 하는 경우, 중복 주문을 막을 수 없는 건가요?

 

A. 네. 302만으로는 중복 요청을 완전히 막을 수 없고 서버에서도 중복 요청 시 해결방안을 마련해야 합니다.

즉, 클라이언트 차원의 중복 요청 방지(PGR) & 서버 차원의 중복 요청 방지(중복된 주문 번호 체크) 모두 필요

 

[출처] https://www.inflearn.com/questions/181131

---

Q. 주문을 POST로 서버에 요청했을 때 아래 2가지 중 실무에서 사용하는 응답 방법은 어떤 방식인가요?

1. 2xx와 함께 "주문완료"를 표현하는 정적 페이지로 응답하는 방법
2. 3xx와 함께 PRG패턴을 적용해 리다이렉트 해주는 방법

A. 결론은 리다이렉션을 사용하는 것이 더 나은 선택이다. 자세한 설명은 MVC 강의에서..

 

[출처] https://www.inflearn.com/questions/224361

 

참고 : https://hseungyeon.tistory.com

 

위 자료는 김영한 님의 ‘모든 개발자를 위한 HTTP 웹 기본 지식’ 강의를 참고하여 작성하였습니다.
https://www.inflearn.com/course/http-웹-네트워크/dashboard