Announcing our new API documentation!
Check it out here
A redirect is a tool used by websites for “rerouting” or sending a visitor to an alternative webpage. An example of a redirect would be when you type “example.com” in your web-browser, but are taken to a different website, like “new-example.com.”
URL redirects are an extremely common practice employed by webmasters and content managers to ensure visitors to their website are reaching their desired content.
When you request a web-page from your browser, there is a server somewhere on the Internet that is receiving your request and responding with the appropriate content. Fundamentally, a redirect occurs when a web-server's response contains a special piece of data (an HTTP response header) instructing the browser to reroute the visitor to an alternative location.
The technical details aside, a browser works by requesting a URL and rendering the page that is returned by the website. If the website wishes the user to be redirected, the server will respond differently than if it was serving a page; it will send an extra piece of data indicating that the visitor should be redirected to a specified location.
Without going into too much of the technical details – a redirect is a behavior performed by a web-browser whenever it receives a response containing a flag (an HTTP header) to do so.
Commonly referred to as a “permanent” redirect.
Indicates to search-engines and web-browsers that the requested page has permanently relocated to a new location.
Note: permanent redirects are often cached by web-browsers like Chrome and Firefox. Therefore, it may be tricky to retroactively update a 301 redirects target location once it has been established. Any visitors who have already received the 301 redirect response for a URL will likely be served a cached response from their web-browser when visiting the same URL again.
Suggestion Only use a 301 redirect when you know that the target location will not change.
Common Uses
Commonly referred to as a “temporary” redirect.
Useful for general-purpose redirects within your website, where you do not want visitor’s to cache the redirect response permanently.
Suggestion Use 302 redirects for pages that have changed URL, but are subject to be updated in the future
Common Uses
Uncommon due to legacy browser support
Used for technical scenarios when a visitor’s HTTP request method should be persisted when they are redirected. For example, if a user submits a form, the browser normally issues a POST request to the form’s action URL. If the server responds with a 302 redirect response, the client’s web-browser would typically issue a GET request when handling the redirect. However, if the server responds with a 307 redirect response, the client’s web-browser will POST request to the redirect destination. Please note, form-data is typically lost when redirecting via POST request.
The most common use-cases that would require a redirect are:
There maybe times where you want to redirect a URL using HTTP 301 status code, which signifies a permanent redirect. However, what if you don't want this redirect to be cached by the browser? This is where the use of the Cache-Control header comes in handy.
This article will explain how to use the Cache-Control header to prevent browsers from caching 301 redirects. Additionally, we will discuss how to implement the various directives on popular web servers.
While the caching of 301 redirects is a good thing in most scenarios - it helps speed up navigation to commonly visited URLs - there may be circumstances where this is not the desired result. For instance, if you're in the process of developing a site and are frequently changing urls and redirects, caching can lead to confusion and erroneous results. Another use-case might be when your site has implemented temporary URL structures that may change over time, and you don't want your users to be stuck with the outdated structures.
The Cache-Control HTTP header is used to specify directives for caching mechanisms of http requests and responses. The directives specify who can cache the response, under which conditions, and for how long.
To prevent browsers from caching a 301 redirect, you can add the Cache-Control header with the no-store directive to your HTTP response. This tells the browser not to store a copy of the document in its cache.
Let's go through a basic example:
In this example, the server sends back a 301 Moved Permanently status code, indicating that the requested resource has been assigned a new permanent URI and any future references to this resource should use one of the returned URIs. The Location field holds the new URI where the resource resides. The Cache-Control header with the no-store directive tells the client (the browser) not to cache this redirect.
The way you add the Cache-Control header will depend on your server software. Below are brief tutorials on how to do this in some popular web servers:
In Apache, you can use the .htaccess file to add headers to your HTTP responses. Lets look at how to implement this below:
In Nginx, you can add headers within a server or location block in your server configuration file. Lets look at how to implement this below:
Remember to reload or restart your server after making these changes for them to take effect.
The Cache-Control header has several other directives that allow you to control how, by whom, and for how long a resource can be cached. Let's look at a few more of these directives.
Unlike no-store, the no-cache directive doesn't prevent the caching of a resource. Instead, it specifies that the stored response must be validated with the server every time before it's served. This ensures that users always receive the most up-to-date version of a resource, while still benefiting from caching.
In other words, no-cache allows a response to be cached, but tells the browser that it must not use the cached response without first checking with the server to see if there are any changes.
The max-age directive specifies the maximum amount of time (in seconds) a resource is considered fresh. Once this time has passed, the cached copy of the resource is considered stale, and the client will re-fetch the resource from the server.
For example, Cache-Control: max-age=3600 means that the resource can be cached, and that cache is valid for one hour.
public and private directives control where a resource can be cached.
If a response is marked public, it can be cached by any cache, including those that are shared among multiple users, such as a CDN. This is useful for resources that are the same for all users.
On the other hand, a response marked private is intended for a single user and must not be cached by a shared cache. A private browser cache (i.e., the cache on a user's local machine) can store such a response.
These directives can be combined to achieve more specific caching policies. For example, Cache-Control: private, max-age=600 means that the response is specific to a single user and can be stored in the user's browser cache for up to 600 seconds.
It's important to remember that while using these directives provides you with greater control over how your responses are cached, not all browsers and caches respect all directives, and the exact behavior can sometimes depend on the specific browser and its version.
Understanding the Cache-Control directives and their respective behaviors can greatly enhance your control over how your web resources are cached. While the no-store directive is particularly useful for preventing caching of 301 redirects, other directives like no-cache, max-age, and public/private provide also additional flexibility for managing web resource caching policies.
