![]()
The true power of Nginx lies within its modules. The entire application is built on a modular system, and each module can be enabled or disabled at compile time. Some bring up simple functionalities, such as the autoindex module that generates a listing of the files in a directory. Some will transform your perception of a web server (such as the Rewrite module). Developers are also invited to create their own modules. A quick overview of the third-party module system can be found at the end of this chapter.
This chapter covers:
- The Rewrite module, which does more than just rewrite URIs
- The SSI module, a server-side scripting language
- Additional modules enabled in the default Nginx build
- Optional modules that must be enabled at compile time
- A quick note on third-party modules
![]()
This module, in particular, brings much more functionality to Nginx than a simple set of directives. It defines a whole new level of request processing that will be explained throughout this section.
Initially, the purpose of this module (as the name suggests) is to perform URL rewriting. This mechanism allows you to get rid of ugly URLs containing multiple parameters, for instance, http://example.com/article.php?id=1234&comment=32—such URLs being particularly uninformative and meaningless for a regular visitor.
Instead, links to your website will contain useful information that indicates the nature of the page you are about to visit. The URL given in the example becomes http://website.com/article-1234-32-US-economy-strengthens.html. This solution is not only more interesting for your visitors, but also for search engines. URL rewriting is a key element to Search Engine Optimization (SEO).
The principle behind this mechanism is simple: it consists of rewriting the URI of the client request after it is received, before serving the file. Once rewritten, the URI is matched against location blocks in order to find the configuration that should be applied to the request. The technique is further detailed in the coming sections.
![]()
First and foremost, this module requires a certain understanding of regular expressions, also known as regexes or regexps. Indeed, URL rewriting is performed by the rewrite directive, which accepts a pattern followed by the replacement URI.
It is a vast topic; entire books are dedicated to explaining the ins and outs. However, the simplified approach that we are about to examine should be more than sufficient to make the most of the mechanism.
![]()
The first question we must answer is: what is the purpose of regular expressions? To put it simply, the main purpose is to verify that a string of characters matches a given pattern. The pattern is written in a particular language that allows for defining extremely complex and accurate rules:
| String | Pattern | Does it match? | Explanation |
| hello | ^hello$ | Yes | The string begins with character h (^h), followed by e, l, l, and then finishes with o (o$). |
| hell | ^hello$ | No | The string begins with character h (^h), followed by e, l, l, but does not finish with o. |
| Hello | ^hello$ | Depends | If the engine performing the match is case-sensitive, the string doesn't match the pattern. |
This concept becomes a lot more interesting when complex patterns are employed, such as one that validates an email addresses: ^[A-Z0-9._%+-]
[email protected][A-Z0-9.-]+\.[A-Z]{2,4}$. Validating a well-formed email address programmatically would require a great deal of code, while all of the work can be done with a single regular expression pattern matching.
![]()
The syntax that Nginx employs originates from the
Perl Compatible Regular Expression (
PCRE) library, which (if you remember
Chapter 2,
Basic Nginx Configuration) is a prerequisite for making your own build, unless you disable modules that make use of it. It's the most commonly used form of regular expression, and nearly everything you learn here remains valid for other language variations.
In its simplest form, a pattern is composed of one character, for example, x. We can match strings against this pattern. Does example match the pattern x? Yes, example contains the character x. It can be more than one specific character; the pattern [a-z] matches any character between a and z, or even a combination of letters and digits: [a-z0-9]. In consequence, the pattern hell[a-z0-9] validates the following strings: hello and hell4, but not hell or hell!.
You probably noticed that we employed the characters [ and ]. These are called metacharacters and have a special effect on the pattern. There is a total of 11 metacharacters, and all play a different role. If you want to create a pattern that actually contains one of these characters, you need to escape the character with a \ (backslash):
| Metacharacter | Description |
| ^ Beginning | The entity after this character must be found at the beginning: - Example pattern: ^h
- Matching strings: hello, h, hh (anything beginning with h)
- Non-matching strings: character, ssh
|
| $ End | The entity before this character must be found at the end: - Example pattern: e$
- Matching strings: sample, e, file (anything ending with e)
- Non-matching strings: extra, shell
|
| . (dot) Any | Matches any character: - Example pattern: hell.
- Matching strings: hello, hellx, hell5, and hell!
- Non-matching...
|
