307 temporary redirect -> 302랑 기능은 같음. 리다이렉트시 요청 메서드와 본문 유지 (요청 메서드를 변경하면 안된다. MUST NOT)
303 see other -> 302와 기능은 같음 리다이렉트 요청 메서드가 get으로 변경..
post로 주문후에 웹 브라우저를 새로고침하면? 중복 주문이 될수잇음
새로고침은 다시 요청
중복 주문이 될수 있다.
PRG (post/redirect/get) 일시적인 리다이렉션 - 예시
post로 주문후에 새로 고침으로 인한 중복 주문 방지
post로 주문후에 주문 결과 화면을 get 메서드로 리다이렉트
새로고침해도 결과 화면을 get으로 조회
중복 주문 대신에 결과 화면만 get으로 다시 요청
즉!!! prg이후 리다이렉트.
URL이 이미 post -> get으로 리다이렉트 됨
새로 고침해도 get으로 결과 화면만 조회...
그럼 뭘 써야함?
302 는 get으로 변할수 있음
307은 메서드가 변하면 안됨
303는 메서드가 get으로 변경
역사는... 처음 302 스펙의 의도는http 메서드를 유지하는것
그런데.. 웹 브라우저들이 대부분 get으로 바꾸어버림 (일부는 다르게 동작)
그래서 모호한 302를 대신하는 명확한 307, 303이 등장함 (301 대응으로 308도 등장)
현실은... 307, 303을 권장하지만 현실적으로 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용... 자동 리다이렉션시에 get으로 변해도 되면 그냥 302를 사용해도 큰 문제가 없다.
302 307 303 리소스의 uri가 일시적으로 변경 따라서 검색 엔진 등에서 url을 변경하면 안됨...
302 Found > 리다이렉트시 요청 메서드가 get으로 변하고, 본문이 제거될수 있음 (MAY)
307 temporary redirect -> 302랑 기능은 같음. 리다이렉트시 요청 메서드와 본문 유지 (요청 메서드를 변경하면 안된다. MUST NOT)
303 see other -> 302와 기능은 같음 리다이렉트 요청 메서드가 get으로 변경..
post로 주문후에 웹 브라우저를 새로고침하면? 중복 주문이 될수잇음
새로고침은 다시 요청
중복 주문이 될수 있다.
PRG (post/redirect/get) 일시적인 리다이렉션 - 예시 post로 주문후에 새로 고침으로 인한 중복 주문 방지 post로 주문후에 주문 결과 화면을 get 메서드로 리다이렉트 새로고침해도 결과 화면을 get으로 조회 중복 주문 대신에 결과 화면만 get으로 다시 요청
즉!!! prg이후 리다이렉트. URL이 이미 post -> get으로 리다이렉트 됨 새로 고침해도 get으로 결과 화면만 조회...
그럼 뭘 써야함? 302 는 get으로 변할수 있음 307은 메서드가 변하면 안됨 303는 메서드가 get으로 변경
역사는... 처음 302 스펙의 의도는http 메서드를 유지하는것 그런데.. 웹 브라우저들이 대부분 get으로 바꾸어버림 (일부는 다르게 동작) 그래서 모호한 302를 대신하는 명확한 307, 303이 등장함 (301 대응으로 308도 등장)
현실은... 307, 303을 권장하지만 현실적으로 이미 많은 애플리케이션 라이브러리들이 302를 기본값으로 사용... 자동 리다이렉션시에 get으로 변해도 되면 그냥 302를 사용해도 큰 문제가 없다.
기타... (300 304) 300은 잘 안씀... 304 Not Modified