요약

  • 1996년 5월 RFC 1945는 302를 Moved Temporarily로 설명하며 POST 뒤에 사용자가 확인할 수 없는 자동 리디렉션을 금했다. 1997년 1월 RFC 2068은 이 경계를 유지하고 일부 클라이언트의 POST→GET 전환을 오류로 기록했으며, 결과를 GET으로 읽는 303 See Other를 정의했다.
  • 1999년 6월 RFC 2616은 302의 이름을 Found로 바꾸고 당시 대부분의 사용자 에이전트가 원래 메서드와 무관하게 Location에 GET을 보낸다고 적었다. 같은 문서는 메서드를 유지할 307 Temporary Redirect를 추가했다. 303은 이미 1997년에 있었다.
  • 2022년 6월 RFC 9110은 역사적 이유로 302 다음 요청에서 POST를 GET으로 바꾸는 것을 허용한다. 307을 자동으로 따를 때는 메서드를 바꿀 수 없다. 두 선택은 제출한 요청 본문이 새 주소로 이동할지를 가른다.

주소가 옮겨질 때 요청도 옮겨지는가

1996년 5월 발행된 HTTP/1.0 규격 RFC 1945는 302를 임시 이동으로 설명했다. 서버가 Location에 다른 주소를 넣으면 클라이언트는 그곳으로 갈 수 있다. 다만 이동은 임시이므로 나중의 요청에는 원래 주소를 계속 써야 했다. 문서를 읽는 GET 요청이라면 그림이 쉽다. 이 주소에서 문서를 찾았더니 잠깐 저 주소에 있다는 뜻이다.

양식 제출은 다른 이야기다. POST에는 사용자가 입력한 내용이 담길 수 있고, 서버가 그 내용에 따라 행동할 수도 있다. 302를 받은 브라우저가 새 주소로 POST를 다시 보내면 요청 본문까지 따라갈 수 있다. GET으로 바꾸면 새 주소에서는 읽기 요청만 발생한다. Location은 목적지를 알려줄 뿐, 제출한 행동을 복제할지 결과를 읽을지까지 저절로 결정하지 않는다.

1996년 문서는 POST 뒤의 302를 자동으로 따를 때 사용자의 확인을 요구했다. 확인할 수 없다면 자동으로 리디렉션해서는 안 된다는 규칙이다. 한 번 제출한 내용을 다른 목표에 다시 보내는 일은 단순히 페이지를 넘기는 일과 다르기 때문이다. HTTP가 장소의 이동과 행위의 이동을 같은 화살표로 표시할 수 없다는 문제가 여기서 시작됐다.

운영자에게는 더 일상적인 요구도 있었다. 양식을 처리한 뒤 완료 화면을 보여주는 것이다. 첫 서버가 제출을 마쳤다면 결과 화면은 GET으로 읽는 편이 자연스럽다. 하지만 서버가 아직 작업을 끝내지 않았고 다른 주소에서 같은 POST를 받아야 한다면 GET 전환은 작업을 끊는다. 같은 302에 두 종류의 후속 요청이 매달리기 시작했다.

1997년 문서는 이미 브라우저와 다투고 있었다

1997년 1월의 HTTP/1.1 규격 RFC 2068은 302를 여전히 Moved Temporarily라고 불렀다. GET이나 HEAD가 아닌 요청을 자동으로 리디렉션하려면 사용자의 확인이 필요하다는 경계도 유지했다. 그 설명 안에는 당시 일부 HTTP/1.0 사용자 에이전트가 302 뒤에서 POST를 GET으로 바꾸는 잘못을 저질렀다는 기록이 들어 있다. 실무의 갈등이 나중에 꾸며진 이야기가 아니라 규격 작성 시점에 이미 관찰됐다는 뜻이다.

이 문서는 303 See Other도 정의했다. POST로 프로그램을 실행하거나 양식을 처리했다면, 서버는 다른 URI에 놓인 표현을 GET으로 가져오라고 알려줄 수 있었다. 제출 행위와 그 결과를 읽는 행위를 구분하는 코드다. 첫 주소에서는 작업을 하고, 두 번째 주소에서는 화면을 가져온다. 굳이 302를 해석하는 브라우저의 습관에 결과 화면을 맡길 필요가 없는 표현이었다.

그렇다고 새 코드가 곧 설치된 프로그램을 바꾸지는 못한다. 서버가 302를 내보내면 어떤 클라이언트는 규격의 확인 절차를 지키고, 어떤 클라이언트는 GET으로 넘어갔다. 결과 화면을 보여주는 데는 후자의 행동이 유용할 수 있었다. 반대로 작업 자체를 다른 주소로 옮기려는 서버에는 원래 POST가 사라지는 문제였다. 프로토콜 작성자는 하나의 숫자에 서로 다른 요청을 기대하는 프로그램들이 달라붙은 모습을 보고 있었다.

연대기를 정확히 나눌 필요가 있다. RFC 1945에는 301 뒤에 일부 클라이언트가 POST를 GET으로 잘못 바꾼다는 별도 언급이 있다. 1996년 302 설명의 중심은 POST 자동 리디렉션을 사용자 확인 없이 하지 말라는 규칙이다. 302 뒤의 POST→GET 전환을 직접 적은 기록은 1997년 문서에서 확인된다. 이 차이를 지워버리면, 실제 문서들이 남긴 순서보다 매끈한 이야기가 된다.

1999년, 규격이 현실의 브라우저를 따라잡다

1999년 6월 RFC 2616은 302의 이름을 Found로 바꿨다. 그 주석은 이전 규격들이 리디렉션 과정의 메서드 변경을 허용하지 않았지만, 당시 존재하던 사용자 에이전트 대부분은 302를 303처럼 취급한다고 적었다. 원래 요청이 POST여도 Location의 주소에는 GET을 보낸다는 것이다. 여기서 ‘대부분’은 규격이 당시 클라이언트를 묘사한 말이지, 이 글이 브라우저 버전별 점유율을 계산한 결과가 아니다.

문서는 두 용도를 더 분명하게 갈랐다. 이미 존재하던 303은 처리된 요청 뒤에 다른 자원을 읽으라는 신호다. 새로 들어온 307 Temporary Redirect는 임시로 주소를 바꾸되 요청 메서드는 그대로 두라는 신호다. POST가 다음 주소에서도 POST여야 하는 서버에는 307이 필요했다. 요청이 끝났고 결과 문서를 읽히려는 서버에는 303이 맞았다. 코드를 더한 이유는 표를 예쁘게 만들려는 욕심이 아니라 다음 주소가 받을 요청을 명확히 하기 위해서였다.

RFC 2616의 호환성 조언은 더욱 노골적이다. 일부 오래된 클라이언트는 303을 모를 수 있으므로, 그런 클라이언트를 상대하는 서버에는 302를 쓰는 방법을 언급했다. 대부분이 이미 그것을 303처럼 처리했기 때문이다. 새 규칙을 만든 문서가 동시에 구식 행동을 실무의 자원으로 다룬다. 실제로 가동 중인 브라우저 집단이 규격의 단어 선택에 영향력을 행사한 장면이다.

POST를 GET으로 바꾸면 새 주소에는 원래 요청 본문이 재전송되지 않는다. 제출이 이미 완료됐고 결과 화면만 필요하다면 유용하다. 그러나 새 주소에서 제출을 계속 처리해야 한다면 필요한 요청이 사라진다. 307을 고르면 반대다. 메서드를 보존하는 리디렉션은 본문까지 새 URI로 가져갈 수 있다. 어느 쪽이든 상태 코드가 결정하는 것은 단순한 주소 교체가 아니라 작업의 진행 방식이다.

2022년에도 남은 관행

2022년 6월 HTTP Semantics RFC 9110은 302 뒤의 POST를 GET으로 바꾸는 것을 역사적 이유로 허용한다. 허용이지 모든 클라이언트에 그렇게 하라는 명령은 아니다. 서버가 메서드 변경을 원하지 않는다면 307을 쓰라고 안내한다. 307을 자동으로 따라갈 때 사용자 에이전트는 요청 메서드를 변경해서는 안 된다.

303은 또 다른 메시지를 보낸다. 원래 요청에 대한 간접적인 응답으로 다른 자원을 가져와 보여줄 수 있고, 일반적으로 GET 또는 HEAD가 그 읽기에 쓰인다. 302는 옛 브라우저의 습관을 품은 채 남았고, 303과 307은 서버가 두 방향 중 어느 쪽을 원하는지 보다 정확히 말하게 해준다. 숫자 하나의 역사가 오늘 서버의 선택지에도 남아 있다.

307이 언제나 더 안전하다고 말할 수는 없다. 메서드가 유지되면 제출 내용이 Location이 가리키는 URI에 도착할 수 있다. 서버가 그곳에 작업을 맡겼다면 의도한 결과지만, 결과 페이지만 보여주려 했다면 불필요한 재전송이다. 반대로 GET으로 바뀌면 그 주소에서 계속돼야 할 POST 작업은 수행되지 않는다. 새 주소가 무엇을 받아야 하는지 정한 뒤 코드를 고르는 순서가 맞다.

이 네 규격에는 어느 브라우저의 어느 출시판이 처음으로 전환을 택했는지 정리한 표는 없다. 그 연대기에는 날짜가 남은 구현 기록이 필요하다. 다만 핵심 변화는 원문만으로 확인된다. 1996년의 확인 규칙, 1997년의 클라이언트 이탈 기록, 1999년의 다수 관행 인정과 307 추가, 2022년까지 이어진 역사적 허용이다.