In this lesson we're going to talk about using location blocks in the engine configuration.
This is the most used context in any engineered configuration and it's how will define and configure
the behaviour of specific you are our eyes or requests.
Think of location blocks as intercepting a request based on its value and then doing something other
than just trying to serve a matching file relative to the root directory as we saw in the previous lesson.
This standard behaviour is great for static resources such as our style sheet to this image etc..
But if we request for example slash greet or any other you are my engine x cannot match a file and instead
serves this default foro for page.
So let's see how to use a custom location context and intercept that greet request and give it some
hypothetical purpose back to the engine X configuration file.
I'll add a location context inside the server context.
But this time the context takes a parameter before opening the context braces.
This parameter being the you are right to match.
So in our case slash greet meaning we can now respond worth redirect or do whatever else we need to
do with this request and essentially manipulate the response.
Let's just return a text string for now say return which takes two arguments.
The response code and the response data to return to the client 200.
So okay with a response body of hello from Engine X greet location.
Save and reload the configuration.
Refresh.
Greet.
And as expected.
We get that string return to us now.
There are several ways of matching you our eyes on location blocks and the one we just used is called
the prefix match.
Meaning that it matches a request.
You are I starting with Slash greet.
So in other words slash greeting is also matched or even another path.
Literally anything starting with Slash greet.
Should we however not want this behaviour.
We can also do an exact match.
By adding the equal sign or modifier before the pattern.
Change that response to show us the update.
Reload the configuration.
Refresh.
And now we get a 4 0 4 as only slash greet is matched.
And this one no longer exists but if we simply navigate to slash greet we get that new message from
the exact match location.
Okay so prefix and exact matches are great but we can go one step further and matsue our eyes with a
regular expression.
This being the reason for installing the PCR library when we installed engine X this time we'll use
a told the character as the match modifier to indicate that this is a regular expression match.
I'll again do a match for Slash greet and let's say any number from 0 to 9.
After that used this same return statement with a new message safe reload the configuration.
Still at slash greet We now get a foro for as of course that matches.
Also looking for a number from 0 to 9 after slash greet add a number to the you are I however.
And again it works very importantly.
Note that this told a modifier is case sensitive.
So if we change one of these characters to an upper case like so.
We're back to a foro for.
To match case insensitive then so disregard that you are right case all together we can simply add an
asterisk after that older like so.
With a new message.
Save reload dry slash greet with the uppercase character Ghen and now it works.
Engine exercise is a priority to each of these.
Location match modifiers with a regular expression being more important than a prefix match.
We can test this by uncomment ing the original prefix.
Make their capital G too.
Exactly as we have it in the browser whilst also leaving the case insensitive regular expression match
safe.
Reload and the regular expression matched all ones regardless even if the order in which these location
blocks are configured the final modifier is what's called preferential prefix which we write as carit
told her.
This is essentially the same as the basic prefix modifier only more important than a regular expression
match save and reload.
The prefix wins over the regular expression.
It's important to understand the order of priority in which engine X matches requests.
So to sum up they are as follows.
Number one is the exact match.
Should an exact match exist for a you are right that will always be the location block used regardless
of any other matching location block.
Second is the preferential prefix.
Again this is the same as the basic prefix match but have priority over regular expression matches.
Third in equal order is the regular expression.
Matches should however both a case sensitive and case in sensitive location match your request.
Not that this should ever really happen.
The first block will be used as engineers has no other way of prioritizing one over the other.
And finally the lowest of the lot is the very basic prefix matched that we looked at first.
Any other match from the variations above will be prioritized over this one.
That covers the basics of creating location context and matching you are rice in the next list and will
cover the basics of Engineers variables.