Home
Jamstack Explorers
Menu

Exploring Netlify Redirects with Phil Hawksworth

404s rewrites and proxies

Time now to look at ways we can use redirects to route traffic to other services and get finer control over 404 pages.

You'll explore:

  • Returning specific 404 pages depending on the requested path
  • Order of precedence in Netlify redirects configurations
  • Rewrites and proxies to third party services
  • The concept of shadowing

Video transcript

Now that we're getting to grips with adding redirect rules and deploying those to Netlify so that they can configure the behavior at the edge network on the CDN, we can start to experiment a little bit more.

So we're getting used to this this notation where we're adding a redirects rule. We're saying which URL we are looking for. What do we want to match? Where would we like to send it? And so far that's been working out just great for us. At the moment, what we're doing is we're not specifying an HTTP status code. So by default Netlify will add its own status code for us. It will default to using a 302, which is a redirect, not a permanent redirect, which is a 301. But instead Netlify will default to adding a 302. We can ask Netlify to return any HTTP status code we like using this notation. So we can start to do some fun things with that. Let's now look at using this to set custom 404 pages and also rather than doing redirects, let's look at doing rewrites and proxies. So let's start off with 404s. The way we might want to declare a particular 404 page to be served... now different static site generators have conventions for this, but we can have complete control over this using using the redirects. What we'll do is we will say we're going to return a status of 404 under the following conditions. So let's do that for any page on the site or any route on the site. And this is the page that we're going to send users to. It just so happens that I've added over here. You'll see in the source code of added and not found page, which will be generated. And then that's where we're going to send people to. Currently we're going to send everybody on every URL to this page. Now there's a concept in redirects, which is important to understand, and that is of shadowing.

So this redirect will be honored as long as we haven't first detected a file that's being generated and is ready to serve. If we can find a file, we'll serve that. If we don't find a file, we will honor this. Which means that on any route, if we can't find a page to return, we will send users to this URL with this status code. We can override that behavior of serving the files we find first, using the force command. As this force value by default is false. So in other words whenever we find a file, we'll serve that. Otherwise we'll honor this redirect. If we want to overwrite that we could set this to true.

And this has some useful properties that we'll talk about in another session. But there's defaults to false. So in other words, it will always serve the files that it finds. And if it can't find a file at a particular URL, it will honor the redirects. So this means that now with this, with this in place, let's do another quick deployment and see that actually on, on Netlify itself. Open up the URL. So now, any file that it finds on any route, it will serve that you can see that we're navigating the site. But if we go to a file, for instance, th about us pages not populated. Now instead, We're going to return for that, the, the contents of the file that we specified in our redirects, this not found page and we'll return a 404.

So this has being served now as a custom 404 page.

We can go a little bit further than that. So this is for every file that wasn't found , on any, any path across the sites, but we can start to be a bit more specific. So if we duplicate that. And start to get a bit more specific. Let's say we want to have a particular custom 404 page for any news item that isn't found. So we're currently serving our blog posts on the news URL. So I've also created a story, not found page. So let's instead of serving the generic one. That say story, not found for any file that couldn't be found, any URL that couldn't be honored from the file system on the news path.

Let's save that we'll do the same again. We'll quickly do a deploy. We'll go off and look at the site. So news is, is our URL for our, our stories. And if I look for some other URL that we couldn't find. Then we'll see. Oh, what's happened here. We're actually seeing the same 404 page. The same generic 404 page. We're not seeing our custom 404 page that we really want to see. The reason for that is right here in front of us. The way that redirects are parsed is that they start, we start at the top of the file and we work our way down. So the first match that Netlify finds is the one that it will honor. Now, in this case, we're doing a much more aggressive wild card match here than here so this is going to be the one that's actioned. If we're being a bit more specific, we should move this more specific rule up. So now we will match, if a request is coming in within the news part of the sites that couldn't be found we'll serve this If other URLs that are being requested outside of that, this will fall through. And if it's not found it will honor this one. So let's save our configuration. for that again, deploy our site.

And let's take another look at this URL. So now if we refresh this, we should get, there we go, we're getting our specific 404 for this. For this section of the site. So that's, that's quite a powerful little feature. It shows that we can start to inspect the requests that are coming in. And determine exactly what kind of 404 or any other status page we might want to return for any particular section of the site. That's a, that's pretty handy.

Let's also look at one of my favorite features, which is rewriting and proxying. So again, we're going to add a redirects rule. Again, we're going to have a from. And we'll have a to. And here, we're going to return a status of 200. Now a 200 is a file found. It's returning a view correctly, it's a success criteria on the web. So what are we going to specify for 200? Well, let's have a look at our site first of all, at the moment we've got this store page, which serves up nicely on the store URL.

Now it might be that for some people in the world, Store is less meaningful than perhaps the word shop. That might be more descriptive. I'm thinking of maybe here in the UK this might sound like a slightly more relatable URL. If I go to this, just to shop up at the moment, there is no shop is we're going to serve our 404 page. It would be nice for this to resolve to the same thing as store. Now we could redirect that. So if someone types shop we have a redirect rule that sends them to the store, but be nice to honore this URL and keep that the same. And we can do that with a rewrite. So let's let's do that now. Let's say for any requests that come in to shop. We're going to rewrite the store with a 200. If we wanted to redirect it, we could just leave out the status code. Or we could specify this as a 301 is a permanent redirect. But instead by adding the 200 there, that means that we will rewrite this request to that URL and returned to the user on the same URL as they typed in the response that comes from that address. So let's have a look at that now, again, we'll open this up and once more, we'll go to forward slash shop. And now what we should see. Yeah. The URL stays the same, but the request has been rewritten to the same, same address as store. So behind the scenes, we're serving that for the shop URL as well. This opens up all kinds of possibilities because not only could we be shaping traffic around our site with a simple bit of configuration, but we could shape traffic to places elsewhere as well. So imagine perhaps that we're going to create an API for our site. It's about time we did that I think. Let's start to add an API we could even call it API. And I think, well, what shall we have we'll have an activity API. We want something that's going to suggest to us things to do.

We're not going to build that ourselves. Instead we'll use something that's elsewhere around on the internet. So let's use this, let's use this boredapi.com. A very helpful resource on the web.

But again, we're going to be redirecting request to API activity to this, this third-party API. Once again, we'll do a little deploy. We'll go off and test this. Open up a page. And now when we go to forward slash API, forward slash activity.

Now we're getting the response from that third party API, but we're doing that via our own site, via the Netlify CDN. So these things aren't having to go client side to a third party resource. So we don't have to deal with things like cross-site requests. These are all going via the site. If we refresh this a few times, we should start getting some use of active yeah. Compliment someone. That sounds pretty good. Clean out your refrigerator. I like that less.

But here we are. So now we're seeing we're getting API requests being sent to our API, which behind the scenes is actually being serviced by a third party API. This is really powerful for making APIs of your own, potentially decoupling the front end from the backend service that servicing these. So we've got great portability now. Now we could create APIs that are initially generated by something elsewhere on the web of third party API or on some of the system that we've created. And then over time we could modify this. So the service which is honoring this request changes over time, but we'll never need to change our front ends to reflect that. So we've got great portability and lovely decoupling there.

So those are just a couple of things that we can do with custom 404s and rewrites and proxies. There's some other interesting things that we can do with proxies, which we'll come on to in another stage.

Explorers

your progress

48