Introduction
Hey there, hope you're doing well! Ready to dive into today's blog about pulling off a 3xx redirection using a CloudFront function? Before we jump in, let's get on the same page about what exactly a 3xx redirection involves.
Quick heads up: To get the most out of this blog, it's important to be familiar with CloudFront functions. If you're not up to speed on them, no worries – check out our blog dedicated to CloudFront functions first, and then come back to supercharge your understanding.
What are Cloudfront functions?
CloudFront functions are designed to empower CloudFront users to apply customized business logic to the ongoing requests processed by AWS CloudFront. These lightweight functions are adept at executing small, efficient tasks at the edge locations during the processing of active requests.
What is a 3xx redirection?
Alright, let's break down 3xx redirects! When your browser gets a 3xx response, it's like a friendly note saying, "Hey, what you're looking for has a new address, go check it out over there!" These codes range from 300 to 308, and each number signifies a unique redirection type. Keep an eye out for 301 and 302 – they're the rockstars of daily redirection use! They're the ones you'll encounter the most in your web adventures.
Different types of 3xx redirects
1. 300 - Multiple Choices
The web server can generate various responses to a request, as the requested resource is accessible in different formats.
2. 301 - Moved Permanently
The requested resource is no longer located at URL A; it has been permanently relocated to URL B. Moving forward, the resource can be accessed exclusively at URL B, rendering URL A obsolete. For comprehensive details on the 301 redirect, please refer to the provided information.
3. 302 - Found (Temporarily displaced)
The requested resource is present on the web server; however, it is temporarily inaccessible at URL A but can be accessed through URL B. The URL A remains valid during this temporary unavailability.
4. 303 - See Other (open other storage location)
The web server notifies the querying client that a distinct GET request must be sent to an alternative storage location to obtain the desired resource.
5. 304 - Not Modified
Since the most recent request from the client to the web server, the resource remains unchanged, and as a result, it will not be transmitted again.
6. 305 - Use Proxy
The web server notifies the client that access to the requested resource is only available through a proxy.
7. 306 - (reserved)
Previously, the directive was to modify the proxy. Currently, the status code is not actively employed but is reserved.
8. 307 - Temporary Redirect
(Comparable to 302/303) The requested resource is present on the web server but is temporarily inaccessible at URL A, instead located at URL B. The URL A remains valid. However, the browser should proceed using the same method as the original request (meaning a POST request is followed by another POST request). For in-depth details, refer to the information on the 307 redirect.
Imagine you're managing a bustling blog website with fresh content pouring in daily. Picture a scenario: you have a blog dedicated to AWS EC2 at the URL "www.somedummywebsite.com/ec2." Suddenly, a decision is made to revamp things, and the new address becomes "www.somedummywebsite.com/aws/ec2."
Now, think about the users who are accustomed to the old URL. If they try to access the blog using the previous address, they'd hit a dead end since the old URL is no longer valid. This is where the magic of redirects comes in.
To ensure a smooth transition and spare users from frustrating errors, the blog site employs a 3xx redirection on the old URL. Here's how it works: when users attempt to reach the blog through the outdated URL, their browser automatically redirects them to the updated address, "www.somedummywebsite.com/aws/ec2." The result? A seamless user experience, all thanks to this intelligent redirection strategy.
Great, let's dive into how we can set up a redirection using CloudFront functions. Now, for this to work, you'll need a CloudFront distribution in place. If you've explored CloudFront a bit, you'll know that it provides two slots where we can plug in our CloudFront function: one for the viewer request and another for the viewer response.
Let's break it down:
1. Viewer Request
If you associate the function with the viewer request, you'll be working with the incoming request data. This means you can inspect and manipulate the request before it reaches the origin server.
Your CloudFront function here will take the request data as input, and based on certain conditions, you can craft a custom response. This is handy if you want to perform logic before the request hits your server.
2. Viewer Response
Now, if you decide to associate the function with the viewer response, you're dealing with the outgoing response data. This is after CloudFront has received the response from your origin server.
In this scenario, your CloudFront function takes the response data as input. Again, you can apply custom logic, maybe modifying headers or response content, before it reaches the end user.
So, it's like choosing between tweaking the request before it heads to the server or fine-tuning the response before it reaches your audience. Depending on your use case, you'll pick either the viewer request or viewer response slot for your CloudFront function. Exciting, right?
Redirection Code
function handler(event)
{
var request = event.request;
var redirectUrl = "https://www.google.com/";
var response = {
statusCode: 301,
statusDescription: 'Moved Permanently',
headers:
{ "location": { "value": redirectUrl } }
}
return response;
}
Summary
In this blog, we delved into the realm of CloudFront functions, exploring their significance. We unpacked the concept of redirections—understanding not just the "what" but also the "how" and "when" behind executing 3xx redirections. To bring these insights to life, we even walked through a practical demonstration.
