The HTTP protocol defines over 40 server status codes, 9 of which are explicitly for URL redirections. Each redirect status code starts with the numeral 3 (HTTP 3xx) and has its own method of handling the redirections. While some of them are similar, all of them go about taking care of the redirections differently.
Understanding how each HTTP redirect status code works is crucial to diagnose or fix website configuration errors.
In this guide, we’ll cover the HTTP 307 Temporary Redirect and 307 Internal Redirect status codes in depth, including their significance and how they differ from other 3xx redirect status codes.
Let’s get started!
What is an HTTP 307 Temporary Redirect?
The Internet Engineering Task Force (IETF) defines the 307 Temporary Redirect as:
The 307 (Temporary Redirect) status code indicates that the target resource resides temporarily under a different URI and the user agent MUST NOT change the request method if it performs an automatic redirection to that URI. Since the redirection can change over time, the client ought to continue using the original effective request URI for future requests.
How HTTP 3xx Redirection Works
Before we dive into the HTTP 307 Temporary Redirect and 307 Internal Redirect responses, let us understand how HTTP redirection works.
HTTP status codes are responses from the server to the browser. Every status code is a three-digit number, and the first digit defines what type of response it is. HTTP 3xx status codes imply a redirection. They command the browser to redirect to a new URL, which is defined in the Location header of the server’s response.
When your browser encounters a redirection request from the server, it needs to understand the nature of this request. The various HTTP 3xx redirect status codes handle these requests. Knowing all of them will help us understand 307 Temporary Redirect and 307 Internal Redirect better.
Check Out Our Video Guide to the 307 Temporary Redirect and All 3xx Redirects
The Various HTTP 3xx Redirections
There are several types of HTTP 3xx redirect status codes. The original HTTP specification didn’t include 307 Temporary Redirect and 308 Permanent Redirect, as these roles were meant to be filled by 301 Moved Permanently and 302 Found.
However, most clients changed the HTTP request method from POST to GET for 301 and 302 redirect responses, despite the HTTP specification not allowing the clients to do so. This behavior necessitated the introduction of the stricter 307 Temporary Redirect and 308 Permanent Redirect status codes in the HTTP/1.1 update.
The HTTP 307 Internal Redirect response is a variant of the 307 Temporary Redirect status code. It’s not defined by the HTTP standard and is just a local browser implementation. We’ll discuss it later in more detail.
While redirect status codes like 301 and 308 are cached by default, others like 302 and 307 aren’t. However, you can make all redirect responses cacheable (or not) by adding a Cache-Control or Expires response header field.
Using 302 vs 303 vs 307 for Temporary Redirects
As seen in the chart above, for temporary redirects, you have three options: 302, 303, or 307. However, most clients treat 302 status code as a 303 response and change the HTTP request method to GET. This isn’t ideal from a security standpoint.
“RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.”
– HTTP/1.1. Status Code Definitions, W3.org
Thus, for temporary redirects where you need to maintain the HTTP request method, use the stricter HTTP 307 Temporary Redirect response.
E.g. redirecting /register-form.html to signup-form.html, or from /login.php to /signin.php.
For cases where you need to change the redirect request method to GET, use the 303 See Other response instead.
E.g. redirecting a POST request from /register.php page to load a /success.html page via GET request.
Unless your target audience uses legacy clients, avoid using the 302 Found redirect response.
Understanding HTTP 307 Internal Redirect for HTTPS-only Sites
If you have a HTTPS-only site (which you should), when you try to visit it insecurely via regular http://, your browser will automatically redirect to its secure https:// version. Typically, this happens with a 301 Moved Permanently redirect response from the server.
For instance, if you visit http://citibank.com and load up DevTools in Chrome and select the Network tab, you can see all the requests made between the browser and the server.
The first response is 301 Moved Permanently, which redirects the browser to the HTTPS version of the site.
If we dig deeper into the Headers fields of the first request, we can see that the Location response header defines what the secure URL for the redirection is.
The problem with this approach is that malicious actors can hijack the network connection to redirect the browser to a custom URL. Man-in-the-Middle (MITM) attacks like this are quite common. A popular TV series even spoofed it in one of their episodes.
Also, a malicious party can launch an MITM attack without changing the URL shown in the browser’s address bar. For instance, the user can be served a phishing page that looks exactly like the original site.
And since everything looks the same, including the URL in the address bar, most users will be happy to type in their credentials. You can imagine why this can be bad.
Secure Redirects with HTTP 307 Internal Redirect
Now, let’s try the same example with Kinsta. Visiting https://kinsta.com leads to network requests as shown in the screenshot below.
The first request by the site is like the previous example, but this time it leads to a 307 Internal Redirect response. Clicking on it will show us more details about this response.
Note: If you try visiting the site directly with https://, you will not see this header as the browser doesn’t need to perform any redirection.
Note the Non-Authoritative-Reason: HSTS response header. This is HTTP’s Strict Transport Security (HSTS), also known as the Strict-Transport-Security response header.
What Is HSTS (Strict Transport Security)?
The IETF ratified HTTP Strict Transport Security (HSTS) in 2012 to force browsers to use secure connections when a site is running strictly on HTTPS.
This is akin to Chrome or Firefox saying, “I won’t even try to request this site or any of its resources over the insecure HTTP protocol. Instead, I’ll change it to HTTPS and try again.”
You can follow Kinsta’s guide on how to enable HSTS to get it up and running on your WordPress website.
Delving deeper into the response header of the second request will give us a better understanding.
Here, you can see the strict-transport-security: max age=31536000 response header.
The max-age attribute of the strict-transport-security response header defines how long the browser should follow this pattern. In the example above, this value is set to 3153600 seconds (or 1 year).
Once a site returns this response header, the browser won’t even attempt to make an ordinary HTTP request. Instead, it’ll do a 307 Internal Redirect to HTTPS and try again.
Every time this process repeats, the response headers are reset. Hence, the browser won’t be able to make an insecure request for an indefinite period.
If you host your site with Kinsta, you can create a support ticket to have the HSTS header added to your WordPress site. Since adding the HSTS header grants performance benefits, it’s recommended that you enable HSTS for your site.
What Is an HSTS Preload List?
There’s a glaring security issue even with HSTS. The very first HTTP request you send with the browser is insecure, thus repeating the problem we observed previously with Citibank.
Furthermore, the HSTS response header can be sent only over HTTPS, so the initial insecure request can’t even be returned.
To address this issue, HSTS supports a preload attribute in its response header. The idea is to have a list of sites that enforce HSTS to be preloaded in the browser itself, bypassing this security issue completely.
Adding your site to the browser’s HSTS preload list will let it know that your site enforces strict HSTS policy, even if it’s visiting your site for the first time. The browser will then use the 307 Internal Redirect response to redirect your site to its secure https:// scheme before requesting anything else.
You should note that unlike 307 Temporary Redirect, the 307 Internal Redirect response is a “fake header” set by the browser itself. It’s not coming from the server, the web host (e.g. Kinsta), or the CMS (e.g. WordPress).
Adding a site to an HSTS preload list has many advantages:
- The web server never sees insecure HTTP requests. This reduces server load and makes the site more secure.
- The browser takes care of the redirection from HTTP to HTTPS, making the site faster and more secure.
HSTS Preload List Requirements
If you want to add your site to a browser’s HSTS preload list, it needs to check off the following conditions:
- Have a valid SSL/TLS certificate installed for your domain.
- Enforce strict HTTPS by redirecting all HTTP traffic to HTTPS.
- All the subdomains should be served over HTTPS, specifically the www subdomain if a DNS record for that subdomain exists.
- Your base domain should include an HSTS header with the following attributes:
- The max-age attribute must be set for at least 31536000 seconds (1 year).
- The includeSubdomains and preload directives must be specified.
- If you’re serving an additional redirect, it must include the HSTS header, not the page it redirects to.
Adding Your Site to the HSTS Preload List
There are two ways to add your site to the HSTS preload list.
- By submitting your site to an HSTS preload list directory. For example, the hstspreload.org master list is maintained by the Chromium open source project and is used by most major browsers (Firefox, Chrome, Safari, IE 11 and Edge).
- By adding the following header field to your site:
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
With the second method, the very first visit to your site by the browser won’t be fully secure. However, subsequent visits will be fully secure.
You can use a free online tool like Security Headers to verify whether or not your site is enforcing HSTS. If you’re worried about browser support for HSTS, you can rest assured knowing that HSTS is supported by almost all browsers in use today.
HTTP 307 Redirects and SEO
Since a 307 Temporary Redirect response shows that the resource has moved temporarily to a new URL, search engines don’t update their index to include this new URL. The ‘link-juice’ from the original URL is not passed on to the new URL.
This is in contrast to 301 Moved Permanently redirects, wherein search engines update their index to include the new URL and pass on the ‘link-juice’ from the original URL to the new URL.
With a 307 Internal Redirect response, everything happens at the browser level. Hence, it should have no direct effect on your site’s SEO. However, adding your site to an HSTS preload list makes it load faster and be more secure, both of which can help it rank higher in search results.
Be careful not to inadvertently redirect users and bots into an infinite redirection loop, causing the ‘too many redirects‘ error.
Summary
URL redirection allows you to assign more than one URL address to a webpage. The best way to handle URL redirections is at the server level with HTTP 3xx redirect status code responses. If your site is down for maintenance or unavailable for other reasons, you can redirect it temporarily to another URL with a 307 Temporary Redirect response.
With that being said, any redirection adds lag to your page load time. Hence, use redirections judiciously keeping the end user’s experience always in mind.
