HTTP Redirection

 

HTTP의 상태 코드 중 3xx대의 상태 코드는 요청을 완료하기 위해 유저 에이전트의 추가적인 조치가 필요하다는 의미를 가진다.

 

• 300 Multiple Choices
• 301 Moved Permanently
• 302 Found
• 303 See Other
• 304 Not Modified
• 307 Temporary Redirect
• 308 Permanent Redirect

 

 

웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면 Location 위치로 자동 이동시킵니다.

 

만약 기존 url을 통해 웹 서비스를 제공했는데, 시간이 지나고 해당 url을 폐지하고 신규 url을 사용해 웹 서비스를 제공한다고 하면, 기존 유저들은 해당 url을 북마크 한 후 사용되지 않는 url로 접근할 수 있습니다.

 

이 경우 서버에서 해당 클라이언트에게 301 Moved Permanently의 응답 코드와 함께 Location 헤더에 새로운 url 경로를 제공해주면 웹 브라우저는 해당 페이지로 리다이렉트 합니다.

 

 

리다이렉션 종류

 

1. 영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동한 경우

 

 301, 308 이 상태코드는 영구 리다이렉션에서 사용되는 코드로 둘 다 기능이 비슷하다.

 

301 Moved Permanently는 리다이렉트 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있다.

 

만약 POST로 예전 URI로 요청을 보내면 서버는 301 리다이렉트 상태 코드를 응답합니다. 이때 HTTP 바디의 내용이 생략되고 새로운 URI로 GET 요청을 합니다.

 

308 Permanent Redirect는 301과 기능은 동일하지만, 리다이렉트 시 요청 메서드와 본문 유지한다.

 

 

2. 일시 리다이렉션 - 일시적인 변경일 때 사용됩니다. PRG: Post/Redirect/GET

 

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

 

307 Temporary Redirect는 302와 기능은 동일하지만 요청 메서드와 본문 유지

 

303 See Other 302와 기능은 동일하며 리다이렉트 시 요청 메서드가 GET으로 변경됩니다. 

 

PRG : POST로 서버에 리소스를 생성한 후 웹 브라우저를 새로고침 하면 서버에 리소스가 중복 생성될 수 있다. 웹 브라우저에서 새로고침은 마지막에 보낸 요청을 다시 보내기 때문이다. 

이를 해결하기 위해선 다음과 같은 방법이 있다. 

 

POST로 리소스 생성 요청 후 결과 화면으로 GET 메서드로 리다이렉트 시키는 방법이 있다. 이후 새로고침인 경우에는 GET메서드로 리다이렉트 된 화면을 재 요청하기 때문에 클라이언트에서 방지할 수 있다.

 

클라이언트 POST 요청 -> 서버에서 처리 -> 클라이언트에게 302 Found , Location: 리다이렉트 주소

-> 클라이언트 해당 주소로 리다이렉트와 같은 순서로 진행되게 된다.

 

* 서버에서 validation도 당연히 해야 한다.

 

 

3. 특수 리다이렉션 - 결과 대신 캐시를 사용 

 

300은 안쓴다. 

304 Not Modified는 매우 자주 사용된다. 캐시를 목적으로 사용되며, 클라이언트에게 리소스가 수정되지 않았음을 알려준다. 따라서 클라이언트는 로컬 PC에 저장된 캐시를 재사용한다. 즉 캐시로 리다이렉트 합니다. 304 응답은 응답에 메시지 바디를 포함하면 안 된다. 로컬 캐시를 사용해야 하기 때문이다.

조건부로 GET, HEAD 요청 시 사용된다.

 

 

 

이제는 어떤 리다이렉트 코드를 써야 할지 고민이 된다. 302는 GET 요청으로 변하고, 307은 메서드 변경이 불가능하고 303은 메서드가 GET으로 반드시 변경된다.  실무적으로 많은 애플리케이션이 302를 기본값으로 사용하고 있다, 따라서 리다이렉션이 GET으로 변해도 되는 경우는 302를 사용해도 문제가 없다.