Creating new rewrite rules

When creating new rules from scratch, just as with any configuration block, plan out exactly what needs to be done. Some questions to ask yourself are as follows:

• What pattern(s) do I have in my URLs?

• Is there more than one way to reach a particular page?

• Do I want to capture any parts of the URL into variables?

• Am I redirecting to a site not on this server, or could my rule be seen again?

• Do I want to replace the query string arguments?

In examining the layout of your website or application, it should be clear what patterns you have in your URLs. If there is more than one way to reach a certain page, create a rewrite rule to send a permanent redirect back to the client. Using this knowledge, you can construct a canonical representation of your website or application. This not only makes for cleaner URLs, but also helps your site to be found more easily.

For example, if you have a home controller to handle default traffic, but can also reach that controller through an index page, you could have users getting to the same information using the following URIs:

/
/home
/home/
/home/index
/home/index/
/index
/index.php
/index.php/

It would be more efficient to direct requests containing the name of the controller and/or the index page back to the root:

rewrite ^/(home(/index)?|index(\.php)?)/?$ $scheme://$host/ permanent;

We specified the $scheme and $host variables because we're making a permanent redirect (code 301) and want NGINX to construct the URL using the same parameters that reached this configuration line in the first place.

If you would like to be able to log individual parts of the URL separately, you can use captures on the URI in the regular expression. Then, assign the positional variables to the named variables, which are then part of a log_format definition. We saw an example of this in the previous section. The components are essentially as follows:

log_format imagelog '[$time_local] ' $image_file ' ' $image_type '' $body_bytes_sent ' ' $status;

rewrite '^/images/([a-z]{2})/([a-z0-9]{5})/(.*)\.(png|jpg|gif)$' /data?file=$3.$4;

set $image_file $3;

set $image_type $4;

access_log logs/images.log imagelog;

When your rewrite rule leads to an internal redirect or instructs the client to call a location in which the rule itself is defined, special care must be taken to avoid a rewrite loop. For example, a rule may be defined in the server context with the last flag, but must use the break flag when defined within the location it references:

server {

  rewrite ^(/images)/(.*)\.(png|jpg|gif)$ $1/$3/$2.$3 last;
  location /images/ {

    rewrite ^(/images)/(.*)\.(png|jpg|gif)$ $1/$3/$2.$3 break;

  }

}

Passing new query string arguments as part of a rewrite rule is one of the objectives of using the rewrite rules. However, when the initial query string arguments should be discarded, and only the ones defined in the rule should be used, place a ? character at the end of the list of new arguments:

rewrite ^/images/(.*)_(\d+)x(\d+)\.(png|jpg|gif)$ /resizer/$1.$4?width=$2&height=$3? last;