摘要

  • 1997 年 HTTP/1.1 的305 Use Proxy要求客户端经由Location指定的代理，重新发出原来的请求。
  • 1999 年规范把这条指令限定为单次请求、仅由源站发出；2014 年规范因在 HTTP 对话中配置代理的安全问题将它弃用。

你到店里问一本书，店员递来一张纸：“先去找我指定的中间人。”纸上甚至写好了中间人的地址。早年的 HTTP 把这种安排做成了状态码：305 Use Proxy。它要改的不是书的位置，而是请求抵达书店前经过谁的柜台。代理坐进通信路径后，就能接收并转送那封信。

1997 年 1 月的 HTTP/1.1 规范 RFC 2068用很短的段落规定：目标资源必须通过Location字段给出的代理访问，接收者应当经由该代理重试。规范对代理的定义是转发代理，接收请求，改写部分消息，再送往原服务器。一个代理绝非纸上的箭头；它是路径上的一台实际机器。

这使305与普通的搬家通知不同。301给出资源的新地址，305试图为原地址安排另一条路。客户端本来可能有自己的代理设置、网络边界和信任选择。源站返回的响应却希望插手下一跳。若一条响应可以决定中间人，协议就必须说清楚这项决定只管哪一次、由谁来发。

1999 年 6 月的 RFC 2616为305补上两道闸门：它只适用于这一笔请求，而且只有源站能生成这种响应。规范的附注直说，RFC 2068 对这两点写得不清，忽视这些限制会带来重大的安全后果。第一道闸门防止一次响应变成客户端长期的代理设置；第二道闸门阻止路径上的代理以源站名义另选代理。一个状态码的注脚，实际是在划分路线控制权。

闸门加上以后，核心做法仍然刺眼：客户端在一次 HTTP 对话中收到改变下一次请求路径的配置。2014 年的 RFC 7231将305标为弃用，并在修订说明中点出原因：通过协议对话内部配置代理存在安全顾虑。问题就在这项任命权：一条 HTTP 响应试图把客户端的下一次请求交给它选定的代理。

2022 年的 RFC 9110仍把305列在状态码表里，同时说明它已经弃用。表格保留一个号码，像博物馆里留下一块老路牌，方便读懂旧地图。路牌曾说目标站可以替访客指定代理；今天的规范不再让这句话指挥交通。

抵达网站前走的路，也是一次访问的一部分。代理会在终点之前接到请求。305试过让终点回信决定这条路，1999 年先限制了回信的权限和期限，2014 年干脆让这项设计退休。留下的教训很具体：谁能选择中间人，必须写在协议的权力边界里。