20. 3XX - 리다이렉션2 | PRG

일시적인 리다이렉션

302, 307, 303

 

• 리소스의 URI가 일시적으로 변경되는것. 실무에서 정말 많이쓴다
• 따라서 검색엔진 등에서 URL을 변경하면 안됨

 

• 302 Found
• - 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)
• 실무에선 대부분 302 많이 사용한다.

 

• 307 Temporary Redirect
• - 302와 기능은 같음
• - 리다이렉트시 요청 메서드와 본문 유지 (요청 메서드를 변경하면 안된다. MUST NOT)

 

• 303 See Other
• - 302와 기능은 같음
• - 리다이렉트시 요청 메서드가 GET으로 변경

---

PRG  : Post/Redirect/Get

일시적인 리다이렉션 - 예시

 

• POST로 주문후에 웹 브라우저를 새로고침하면?
• 새로고침은 다시 요청
• 중복 주문이 될 수있다.

이런건 중복주문 안되도록 서버에서 잘 막아놔야한다. (원칙적으로는)

 

• POST로 주문후에 새로 고침으로 인한 중복주문 방지 (클라이언트 차원에서 방지 가능. 사용자 사용측면에서도 이게좋음)
• POST로 주문후에 주문 결과화면을 GET 메서드로 리다이렉트 (주문 결과화면으로 리다이렉트)
• 새로고침해도 결과 화면을 GET으로 조회
• 중복 주문 대신에 결과 화면만 GET으로 다시 요청

PRG 이후 리다이렉트

- URL이 이미 POST에서 GET으로 리다이렉트 되었음으로 새로 고침해도 GET으로 결과화면만 조회된다

---

그래서 뭘 써야하나요?

302, 307, 303

 

잠깐 정리

302 Found → GET으로 변할 수 있음

307 Temporary Redirect → 메서드가 변하면 안됨

303 See Other → 메서드가 GET으로 변경 

 

역사

처음 302 스펙의 의도는 HTTP 메서드를 유지하는것

그런데 웹 브라우저들이 대부분 GET으로 바뀌어버림 (일부는 다르게 동작)

그래서 모호한 302를 대신하는 명확한 307, 303이 등장함 (301 대응으로 308도 등장)

 

현실

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

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

---

기타 리다이렉션

300, 304

 

• 300 - Multple Choices : 안쓴다

 

• 304 - Mot Modified (진짜 많이씀)
• - 캐시를 목적으로 사용
• - 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서 클라이언트는 로컬 PC에 저장된 캐시를 재사용한다. (캐시로 리다이렉트 한다.)
• - 304 응답은 응답에 메시지 바디를 포함하면 안된다. (로컬 캐시를 사용해야 함으로)
• - 조건부 GET, HEAD 요청시에 304를 사용한다.