서버가 당신의 중개인을 채용하려던 시절

요약

• 1997년 HTTP/1.1의 305 Use Proxy는 Location에 적힌 프록시를 통해 같은 요청을 다시 보내라고 했다.
• 1999년 문서는 지시 대상을 한 번의 요청과 원 서버의 응답으로 좁혔고, 2014년 문서는 HTTP 대화 안에서 프록시를 설정하는 보안 우려 때문에 이 상태 코드를 더 이상 권장하지 않았다.

서점에 책을 물었더니 서점이 직접 고른 중개인의 주소를 내민다. “이 사람을 거쳐 다시 물으세요.” 책은 여전히 서점에 있다. 달라진 것은 질문이 통과하는 창구다. 예전 HTTP의 305 Use Proxy는 바로 그런 응답이었다. 서버가 프록시 주소를 답장에 넣고 클라이언트에게 그 길로 다시 오라고 했다.

1997년 1월의 RFC 2068은 Location에 표시된 프록시를 통해 자원에 접근해야 하며, 응답을 받은 쪽이 그 프록시로 요청을 반복한다고 적었다. 같은 규격에서 프록시는 요청을 받고 필요에 따라 메시지를 다시 꾸려 앞으로 보내는 전달자다. 길 위에 세운 창구는 실제 요청을 받아 보는 기계다.

그래서 305는 익숙한 이사 안내와 다르다. 301은 자원의 새 주소를 알려 준다. 305는 원래 자원은 두고 그곳까지 갈 경로를 바꾸려 했다. 클라이언트에는 이미 자체 프록시 설정과 네트워크 신뢰 기준이 있을 수 있다. 목적지에서 돌아온 답장이 그 선택에 관여한다면, 지시가 몇 번의 요청에 적용되는지, 누가 발행할 수 있는지 선명해야 한다.

1999년 6월의 RFC 2616은 두 가지 제한을 더했다. 305는 이번 요청 한 번에만 적용되고, 원 서버만 생성할 수 있다. 주석은 1997년 문서가 두 제한을 명확히 하지 않았으며, 지키지 않으면 심각한 보안 결과가 따른다고 말한다. 하나는 답장 하나가 장기간의 프록시 정책을 바꾸는 일을 막는다. 다른 하나는 경로상 중개인이 원 서버 대신 다음 중개인을 지명하는 일을 막는다.

RFC 2616의 프록시 보안 절은 이 위험에 실물을 붙인다. 프록시의 로그에는 개인과 조직의 민감한 정보가 남을 수 있고, 캐시의 내용은 요청이 끝난 뒤에도 남는다. 훼손된 프록시는 공격에 악용될 수 있다고 규격은 경고한다. 따라서 305를 중간 서버도 보낼 수 있다고 읽으면, 이미 길목에 선 장비가 클라이언트의 다음 요청을 자신이 고른 다른 장비로 돌리는 상황이 열린다. 한 번의 요청이라는 제한까지 놓치면 그 선택이 이후 요청으로 번진다. 두 제한은 문장 다듬기가 아니라, 누가 프록시의 로그와 캐시에 트래픽을 맡길 수 있는지 가르는 잠금장치였다.

제한이 생겨도 핵심 구조는 남았다. 프록시 설정이 바로 그 경로를 바꿀 HTTP 대화 안에서 전달됐다. 2014년의 RFC 7231은 305를 사용 중단 대상으로 표시했다. 개정 설명은 프로토콜 안에서 프록시를 설정하는 보안 우려를 이유로 들었다. 중간 길목을 고를 권한이 HTTP 응답 안에 놓인 설계가 결국 퇴장했다.

2022년의 RFC 9110은 상태 코드 표에 번호를 남기되, 더 이상 쓰도록 권장되지 않는다고 설명한다. 옛 노선 번호를 기록에서 지우지는 않았다. 과거 응답을 읽는 사람에게는 도움이 되지만, 표지판의 명령은 현행 길 안내가 아니다.

프록시는 목적지에 닿기 전에 요청을 받는다. 그 자리에 누구를 앉히는지 결정하는 일은 경로에 대한 권한이다. 305는 서버의 답장에 그 권한을 주려 했고, 1999년에 울타리를 얻었으며, 2014년에 퇴장했다. 작은 숫자 하나가 인터넷의 중간 좌석을 누가 배정하는지 묻는다.