HTTP 306 Unused

Quick reference

What Switch Proxy was supposed to do

In early HTTP/1.1 drafts, the concept behind code 306 was a server instruction telling the client to send subsequent requests through a different proxy. The client would receive a response containing the new proxy address and would be expected to switch all future communication through that proxy for the session. The idea was to allow dynamic proxy reassignment — for load balancing, geographic routing, or corporate proxy enforcement — directly from the server side over the HTTP channel itself.

The mechanism was never fully specified, never assigned a finalized response format, and never implemented in any shipping software. The concept was withdrawn during the standardization process of HTTP/1.1 before RFC 2068 (the first published HTTP/1.1 RFC) was finalized.

Why it was withdrawn

The security problem with Switch Proxy is the same fundamental issue that caused 305 Use Proxy to be deprecated: a server can instruct a client to redirect all its traffic through an arbitrary proxy. If an attacker can insert a 306 response — via a man-in-the-middle attack, a compromised intermediary, or a cache poisoning attack — they can redirect all the client’s subsequent requests through a proxy under their control. That proxy can intercept credentials, session cookies, and any unencrypted request or response content.

Out-of-band proxy configuration (operating system proxy settings, browser settings, PAC files, WPAD) does not have this problem because it is controlled by the user or network administrator, not by an arbitrary server. HTTP-based proxy switching was considered too dangerous to standardize.

RFC 7231 (and subsequently RFC 9110) explicitly removed the Switch Proxy concept and reserved the 306 code number to prevent any new specification from reusing it for a different purpose, which could cause interoperability problems with existing software that might be hardcoded to react to 306.

How IANA-reserved status codes work

The IANA HTTP Status Code Registry controls the allocation of status codes. Codes can be in one of several states: Assigned (active, defined semantics), Unassigned (available for future registration), or Reserved (retained by IANA, not available for new registration). Reserved codes are held so that no new specification can claim them, typically because the number has historical significance or must not be reused to avoid breaking existing deployments.

Code 306 falls into the reserved category alongside a few other codes that were once considered but never finalized. The reservation is a tombstone: the number is taken, nothing meaningful occupies it, and new specifications cannot claim it.

This is distinct from unassigned codes like 427 or 430, which are simply gaps in the range that a future RFC could register with new semantics.

What RFC 9110 says

RFC 9110 §15.4.7 states: The 306 status code was defined in a previous version of this specification, is no longer used, and the code is reserved. The specification provides no response format, no client behavior definition, and no server generation rules because the code is entirely inert from a protocol perspective.

The section exists solely to occupy the number and prevent a future document from inadvertently assigning 306 a new meaning without recognizing its history.

If you encounter 306 in the wild

A server returning 306 today is running software that either: predates the withdrawal of the code (extremely old legacy software), has a custom non-standard usage of 306 as an application-level signal, or has a bug generating the wrong status code. In all cases, the response body is the only reliable place to find out what the server actually means.

As a developer, if you discover your software is emitting 306, replace it with an appropriate standard code. For redirect scenarios, use 301 (permanent, method may change), 308 (permanent, method preserved), 302 (temporary, method may change), or 307 (temporary, method preserved). For proxy configuration, do not use HTTP status codes — configure proxies at the network or application layer.

HTTP redirect code comparison

Frequently asked questions

What does HTTP 306 mean?

HTTP 306 has no defined meaning. It was assigned to a concept called Switch Proxy in a pre-standard HTTP draft but was never published as part of any finalized RFC. RFC 9110 marks it as unused and reserved.

Can a server return HTTP 306?

A server must not return 306 in any new implementation. RFC 9110 explicitly states that 306 is no longer used and the code is reserved. Any server returning 306 is either running legacy code or producing it in error.

How should a client handle HTTP 306?

Per RFC 9110, an unrecognized status code in the 3xx range should be treated as 300 Multiple Choices. A compliant HTTP client receiving 306 today should treat it as a generic 3xx response with no redirect semantics.

What was Switch Proxy?

Switch Proxy appeared in draft versions of HTTP/1.1 as a mechanism to instruct clients to change their proxy configuration. The idea was abandoned because it posed the same security risks as 305 Use Proxy: a malicious server could redirect all client traffic through an attacker-controlled proxy.

Related guides

HTTP 305 Use Proxy (deprecated) · HTTP 307 Temporary Redirect · HTTP 308 Permanent Redirect

Standards reference

Definitions from the IANA HTTP Status Code Registry and RFC 9110 §15.4.7. Human-readable guidance by ErrorLookup. · HTTP 306 quick reference →