3xx 일시적리다이렉션, PRG

영구리다이렉션과 다르게 검색엔진에서 url을 변경하면안된다. 다음에 어떻게 될 지 모르기 때문이다. 

302 303은 비슷한데 실무에선302를 사용한다. 별 문제는 없다.

 

 

---

PRG패턴을 알아보자.  상품을 주문하고 주문하기 버튼을 누른다고 하자. 그럼 post메서드로 서버로 내 데이터가 넘어갈 것이다.  자 그런상태에서 결과가 남아있다. 거기서 웹브라우져를 새로고침하면 어떻게 될까? post데이터가 한번 더 들어가서 서버에 중복주문이 들어갈 수도 있다. 요청했던 것을 새로고침해서 새로고침도 post요청이 또 되버리는 것이다,  이것을 해결해야한다.! PRG 사용 전부터 보자.

 

주문데이터가 요청이 와서 딱 저장이 됐다. 근데 클라이언트에서의 마지막 요청이 무엇이었나? 주문이었다. 실수로 새로고침누르면 마지막 요청을 또다시 보내는 것이다. 그냥 화면을 갱신하고 싶었던 것 뿐인 의도와 다르게 post가 한 번 더 들어가서 주문이 계속들어간다. 물론 이건 서버에서 잘 막아야하긴한다. 그래도 클라이언트차원에서 막아줘야한다. 

 

그래서 PRG를 사용한다.

새로고침해도 GET으로 결과화면을 조회하는 것이다. 결과 화면만 GET으로 다시 요청하는 것이다.

 PRG패턴을 사용하는 경우이다. 맨 앞 주문완료를 똑같이 했다 하지만 이번엔 서버에서 응답을 200코드 주지않고 302나 303을 준다. 새로운 URL 리소스를 Location헤더에 넣어서 말이다. 클라이언트는 응답을 받고 GET으로 바꾼 뒤 다시 요청한다. 이번엔 주문 DB를 또 쌓는 것이 아니라 서버에서 리소스정보를 조회해서 비로소 주문완료 HTML화면과 200번대 성공을 넘겨준다. 이 다음 고객이 실수로 새로고침을 해도 다시 5번 GET요청이 반복되는 것 뿐이다. 이렇게 중복주문이 해결된다.

 

URL이 이미 POST에서 GET으로 바뀌었으므로 새로고침을 해도 GET결과 화면만 조회된다. 이 패턴을 사용하면 많은 오류가 줄어든다. 실무에서 아주 많이 사용한다.

 

---

304는 뒤에서 자세히 말하겠다.  캐시를 목적으로 사용한다. 어떤 사진이미지가 있다고하자. 클라이언트가 '캐시(임시저장데이터) 만료된 것 같은데 서버 니가 다시 좀 보내줘라'하면  서버가 '그냥 써도돼 아직, 데이터 안줄거야 니 캐시에 있는 거 갖다써' 이러면 네트워크 다운로드 용량이 많이 줄 것이다. 이미지자체를 보낼 필요가 없으니깐. 따라서 클라이언트는 캐시를 재사용한다. 

 

 

참고

https://www.inflearn.com/course/lecture?courseSlug=http-%EC%9B%B9-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC&unitId=61780&tab=curriculum