이번 TIL은 인프런의 "모든 개발자를 위한 HTTP 웹 기본 지식"을 학습하고, 정리한 내용입니다.
만약, 제 글의 내용을 퍼갈 시에는 " 모든 개발자를 위한 HTTP 웹 기본 지식 "도 출처에 첨부하시기 바랍니다.
요청을 완료하기 위해 유저 에이전트의 추가 조치 필요
예를 들어서,
경로/event
인 이벤트 페이지가 있다. 과거에 이 경로로 된 이벤트 페이지를 여러 군데 뿌렸다.
그런데, 더이상 /event
를 안 쓰고, /new-event
라는 페이지를 경로로 쓰기로 했다.
그럼 기존에 경로/event
페이지로 북마크를 해둔 사용자들은 어떻게 해야 하나??
서버는 경로/event
를 받으면, 301 코드를 내고 새로운 경로를 Location으로 준다.
그러면, 300대 시리즈이고, Location이 해더 필드에 있으면, 웹 브라우져가 자동으로 Location에 저장된 새로운 경로로 바꾼다.
그리고 새로 저장된 경로로 다시 한 번 서버에 요청한다.
그제서야, 서버는 200대 OK 코드와 함께 HTML 파일을 보내준다.
사용자 입장에서는 이 과정이 너무 빨라서, 인식을 못한다.
영구 리다이렉션
일시 리다이렉션
특수 리다이렉션
301과 308 사실상 두 개의 기능이 똑같다. 둘 다 경로가 완전히 바뀌었다는 것을 알려준다.
그런데, 큰 차이점이 하나 있다.
301은 POST 방식으로 리다이렉트 요청을 했는데, 그게 POST에서 GET으로 다 바뀌고 본문 자체가 다 제거될 수있다. => 거의 대부분 이런 식으로 동작한다.
308은 POST 방식으로 리다이렉트 요청을 받았고 어떤 데이터가 내부에 있다면, 리다이렉트로 POST 방식을 유지하고 message body 내의 데이터도 유지한다.
/event
가 "이벤트 참여"라고 해보자!! 그러면, 이벤트 참여를 위한 고객의 이름과 나이를 보낼 것이다. 근데, /event
가 더이상 사용되지 않는 URI라서 새로운 URI를 301 코드와 함께 보내줬다.
그것을 받은 클라이언트의 웹 브라우져는 301 코드를 확인하고, 처음에 등록을 위해 POST 방식으로 보냈던 요청을 GET 요청으로 보낸다. 그리고 message body에 담겨있던 "회원 정보"는 사라지게 된다.
그러면, 처음부터 이벤트 페이지를 다시 입력해야 하는 폼이 나오거나, 새로운 이벤트 페이지에 대한 화면이 나올 것이다.
즉, 사용자가 등록하려고 했던 "회원 정보"를 처음부터 다시 시작해야 한다.
301의 예시와 같은 문제를 308로 해결할 수 있다.
그런데, 실무에서는 거의 이런 식으로 사용하지 않는다.
왜냐면, /event
-> /new-event
로 바뀌면, 내부적으로 전달해야되는 데이터 자체가 다 바뀌어버린다. 그러기 때문에, 사실 이런 경우에는 POST로 들어와도 그냥 GET으로 다시 돌리는게 낳다.
그래서, 308을 거의 못 본다. 그나마 301 사용하지만, 301도 많이 사용하지는 않는다.