Summary

  • The 1997 HTTP/1.1 specification's 305 Use Proxy told a recipient to repeat a request through the proxy named in Location.
  • The 1999 revision confined the instruction to one request and origin-server responses; the 2014 specification deprecated it because in-band proxy configuration raised security concerns.

Imagine asking a shop for a book and getting a reply that says, “Speak to my middleman first; here is his address.” That is a remarkably different instruction from “the book moved to another shelf.” HTTP once had a status code for it. 305 Use Proxy put the name of an intermediary in a response header and asked the client to reroute its request through that intermediary. The shop was trying to choose the road as well as the destination.

RFC 2068, the January 1997 HTTP/1.1 specification, described the scheme in three short sentences. The requested resource had to be accessed through the proxy in Location; the field carried the proxy's URL; the recipient was expected to repeat the request through it. An HTTP proxy was already more than a signpost: the same specification described it as a forwarding agent that receives a request and passes it onward, potentially rewriting the message. Sending traffic through one changes who sits in the path.

The code lived among the redirection statuses, but it did a stranger job than an ordinary move. A 301 points to a new URI for the resource. A 305 tried to keep the resource and change the route taken to reach it. That distinction determines whose decision the response is making. A destination may have good reasons to prefer a particular access path; a client also has its own proxy settings, network constraints and trust decisions. The protocol text had to say how far the destination's instruction could travel.

RFC 2616, published in June 1999, supplied the missing fences. A 305 applied to a single request, and only an origin server could generate it. Its note explicitly says that RFC 2068 had been unclear on those two limits and that ignoring them had significant security consequences. The first fence stopped one response from rewriting a client's general proxy policy. The second kept an intermediary from appointing another intermediary in the origin's name. These were restrictions on the power of a response, written directly into the status-code definition.

Those restrictions still left the central proposal intact: proxy choice arrived inside the very HTTP exchange it was meant to influence. That made the mechanism uncomfortable as a general routing authority. The 2014 HTTP semantics specification, RFC 7231, marked 305 deprecated and named the reason in its change summary: security concerns about configuring a proxy in-band. The security concern reached the proxy-selection mechanism itself: the response was trying to appoint the machine that would receive the next request.

The 2022 HTTP semantics specification, RFC 9110, still lists 305 so a reader of old protocol material can identify it, and says it is deprecated. A number remains in the table after the authority it once claimed has been withdrawn. That is a useful historical fossil. It marks a moment when the web briefly imagined that a response from a destination could decide the next middleman.

The road to a site is part of the transaction. It determines which machine receives the next request before the destination does. 305 treated that road as a choice a server could send back in Location. The later standards drew the boundary more carefully, then closed the booth. The web kept the address of the old idea and stopped asking travellers to take the detour.