1. HTTP (Hypertext Transfer Protocol)

  1. HTTP Redirection
    1. Status codes
      1. 303 See Other
      2. 307 Temporary Redirect
      3. 308 Permanent Redirect
      4. Other redirection mechanisms
    2. Server Implementation
    3. Client implementation
      1. Re-requests
      2. History stack
      3. Permanent redirect handling
    4. Open Redirects
    5. Referenced specifications

HTTP Redirection

There are several different uses for redirection:

  • Signaling that a domain name or path has changed
  • Pointing a client to the result of an operation
  • URL shortening
  • Privacy protection relating to use of the Referer header

Status codes

There's three broad classes of redirects, where a server will want the client to make a new HTTP request:

303 See Other

303 (See Other) is used when the request has been fully processed, and the results of the operation are available at another URI. This is typically used for redirecting Web browsers that have submitted a POST request. This is called a POST/redirect/GET flow. Using this flow ensures that the page being displayed to the user is not associated with a POST request, ensuring that refreshing the page or navigating backwards does not prompt the user to re-submit the form.

307 Temporary Redirect

307 (Temporary Redirect) is used when the server would like the client to re-issue the request at a new URI, but for some reason does not want the client to rewrite bookmarks.

308 Permanent Redirect

308 (Permanent Redirect) is used to indicate the server did not process the request because the resource that handles the request has moved to a different URI. The client should re-issue the request at the new URI, and re-write any references it has on the old URI to the new one.

Other redirection mechanisms

Scripting and HTML meta tags are also capable of automatically redirecting users to a new webpage. These mechanisms typically keep the page in the history stack, which frustrates users trying to navigate backwards; and they are less descriptive than their HTTP counterparts. If at all possible, Web applications should always use HTTP status codes to perform redirection.

Server Implementation

For the main article on server-side implementation of redirects, see the page for the respective HTTP status code.

Client implementation

Clients should be prepared for any request to result in a redirection. This allows the server increased flexibility in deciding how to manage its application space, and reduces the chance that server changes will cause client breakage.


Unless otherwise specified by the application or user, the HTTP library should transparently handle the redirect, discarding the contents of the redirecting response (if any), and re-making the request at the redirect target, providing the contents of the redirect target (if it is not itself a redirect).

If the target of the redirect is itself a redirect, redirect logic should be applied recursively until either a maximum number of redirects have been applied (typically 10), or until a page is re-requested twice with the same method (which indicates a redirect loop). These cases should result in a client-emitted error describing a problem with the server.

History stack

Users typically use the history stack to re-view the same content they had seen previously. So unless otherwise specified, the user's history stack should store the redirected location in place of the requested one.

Permanent redirect handling

Libraries should allow applications to specify a permanent redirect handler which notifies the application that a URI has been renamed. Libraries emitting this event should make available the requested, old URI; the new URI to update to; and the response body that may provide information on why the permanent redirect is being issued.

Applications receiving this event should log it, then modify old URIs to point to the new one.

Open Redirects

An open redirect is a case where a Web server accepts an option for where to redirect requests to, including off-site. For example, this PHP file will redirect the user to a target as specified in the URL parameters:

header('HTTP/ 303 See Other');
header('Location: ' . $_GET['target']);

An open redirect is not by itself a vulnerability, however open redirects are a serious code smell; they are frequently combined with other vulnerabilities as part of a larger attack; and attackers may use an open redirect that prey's on a user's trust of the authority to get them to click on the link, which then redirects to a malicious website.

In general, you should not permit applications with an open redirect.

Referenced specifications