--back. Next up, I want to add a feature that redirects boom.com to www.boom.com. We could also go the other way, where you might want to redirect anything to just the regular boom.com. That became kind of a fashionable thing to do for a while.
But I highly recommend that you do it the other way so that you have www in front of it. It makes your life a lot easier for a ton of other use cases. So right now, what we have is a server block where the server name is boom.com. We're listening on port 80. We've said this is the default server.
But we're returning 200. And instead of doing that, I'm going to return a redirect. So the redirect code is 301. If you forget what the codes are, you can always look them up on Google, HTTP status codes.
And what we're going to do is to redirect to a particular location. So with the 301 status code, we can provide that location as the second parameter and nginx will know what to do automatically. So we want to do here is to redirect this to www.boom.com.
And we're going to add to this a variable that we get for free from nginx. Variables are accessed using the dollar sign and then the name of the variable. And in this case, the one we want to use is called request_uri. So that's going to be the rest of the path of the request.
And then in front, we want to make sure that we redirect both HTTP and HTTPS. So I can use a variable called the scheme for that. So $scheme. Now any request that comes into port 80 on the server named boom.com or where it's requesting the host name boom.com, it'll get redirected to this other host name here. And I'm going to get rid of this default server option because now we're going to make another server block.
And I'll just go ahead and copy this. And the server name this time is going to be www.boom.com. And we'll make this the default server. We're not going to hook this up to our application quite yet. Just to make things simple, I'll return a status code of 200. And everything is good to go. I'll say good to go so we know for sure.
Great. And now we have simple redirect working. Next up, ssh into the deploy machine. And we need to reload nginx. And again, if you want to just double-check that you got syntax correct, you can say sudo nginx and provide it the -t option. And it'll tell you that everything is OK.
And just to double-check, I can curl the local host and make sure we're still good to go. Excellent. Now I'm going to show you a trick that works on Mac or Unix machines. And if you're on Windows, you're going to have to figure out how to do this. Sorry about that.
But what I want to do is I want to be able to curl or go into my browser and go to the boom.com. And instead of doing a regular DNS lookup, I want to automatically forward those requests to the IP address of my choice. To do that, I can edit a file that is in the /etc folder, and it's called hosts.
You'll need to be a privileged user in order to edit this file, so use sudo privileges and type in your password. This file serves as a sort of local domain lookup. Notice the IP address over on the left, 127.0.0.1. That's going to map to the local host. That's why we're able to just use this keyword here in order to get to this IP address.
We're going to add our own IP address down at the bottom. It will be 192.168.33.10, the IP address of our virtual machine. And we're going to say that if you go into the browser and you navigate to boom.com, that's going to point to this IP address. And we'll do the same thing for www.boom.com. So we can have many different mappings here.
Then I'll just save and quit the editor. So this is really useful for testing out different deployment configurations locally. And for instance, if you want to test out SSL or redirects or things like that using the regular domain name for your application, you can just map that host name directly into that /etc host file and treat it like it's already deployed on the internet. And SSL will work correctly and the redirecting that we're trying out now will work correctly.
So to try it out, let's type curl. And I'm going to inspect the headers, so we'll do -i. And I'll just take a look at boom.com. We get back our nginx response. And notice the status code is a 301. That means it's been moved permanently, this resource. And it gives us another header, which is the location.
So it's saying go ahead and go here now to find the new resource. And in case you navigate here in a browser and it doesn't redirect properly, you'll end up seeing this HTML. But most of the time, the browser will automatically redirect to this location and follow this.
And if we do any other resource-- for example, let's say curl -i boom.com hello world, just some made up URL, it'll do the same thing, except this time that the request URI's a bit different. So the location will be HTTP. That's our scheme. Here's the new host. And here's the request URI.
If we go directly to the correct URL-- so I look at a http://www.boom.com, we should just get the good to go message. And I can tell curl to automatically follow the redirect by using the -L option.
So when I press Enter this time, notice that it automatically redirects me. And I get the good to go message down at the bottom. So doing redirects is really fast in nginx, really easy to do. And we didn't have to hit the application stack at all for this. It just went right to nginx and came back immediately. So we saved a little bit of CPU, memory, and the time that it takes to exercise our application.