# rewrite

*rewrite* performs internal message rewriting. Rewrites are invisible to the client.
There are simple rewrites (fast) and complex rewrites (slower), but they're powerful enough to
accommodate most dynamic back-end applications.

## Syntax

~~~
rewrite FIELD FROM TO
~~~

* **FIELD** is (`type`, `class`, `name`, ...)
* **FROM** is the exact name of type to match
* **TO** is the destination name or type to rewrite to

When the FIELD is `type` and FROM is (`A`, `MX`, etc.), the type of the message will be rewritten;
e.g., to rewrite ANY queries to HINFO, use `rewrite type ANY HINFO`.

When the FIELD is `class` and FROM is (`IN`, `CH`, or `HS`) the class of the message will be
rewritten; e.g., to rewrite CH queries to IN use `rewrite class CH IN`.

When the FIELD is `name` the query name in the message is rewritten; this
needs to be a full match of the name, e.g., `rewrite name miek.nl example.org`.

If you specify multiple rules and an incoming query matches on multiple (simple) rules, only
the first rewrite is applied.


> Everything below this line has not been implemented, yet.

~~~
rewrite [basename] {
    regexp pattern
    ext    extensions...
    if     a cond b
    status code
    to     destinations...
}
~~~

* basepath is the base path to match before rewriting with a regular expression. Default is /.
* regexp (shorthand: r) will match the path with the given regular expression pattern. Extremely high-load servers should avoid using regular expressions.
* extensions... is a space-separated list of file extensions to include or ignore. Prefix an extension with ! to exclude an extension. The forward slash / symbol matches paths without file extensions.
* if specifies a rewrite condition. Multiple ifs are AND-ed together. a and b are any string and may use request placeholders. cond is the condition, with possible values explained below.
* status will respond with the given status code instead of performing a rewrite. In other words, use either "status" or "to" in your rule, but not both. The code must be a number in the format 2xx or 4xx.
* destinations... is one or more space-separated paths to rewrite to, with support for request placeholders as well as numbered regular expression captures such as {1}, {2}, etc. Rewrite will check each destination in order and rewrite to the first destination that exists. Each one is checked as a file or, if it ends with /, as a directory. The last destination will act as the default if no other destination exists.
"if" Conditions

The if keyword is a powerful way to describe your rule. It takes the format a cond b, where the values a and b are separated by cond, a condition. The condition can be any of these:

~~~
is = a equals b
not = a does NOT equal b
has = a has b as a substring (b is a substring of a)
not_has = b is NOT a substring of a
starts_with = b is a prefix of a
ends_with = b is a suffix of a
match = a matches b, where b is a regular expression
not_match = a does NOT match b, where b is a regular expression
~~~

## Examples

When requests come in for /mobile, actually serve /mobile/index.
rewrite /mobile /mobile/index
If the file is not favicon.ico and it is not a valid file or directory, serve the maintenance page if present, or finally, rewrite to index.php.

~~~
rewrite {
    if {file} not favicon.ico
    to {path} {path}/ /maintenance.html /index.php
}
~~~

If user agent includes "mobile" and path is not a valid file/directory, rewrite to the mobile index page.

~~~
rewrite {
    if if {>User-agent} has mobile
    to {path} {path}/ /mobile/index.php
}
~~~

If the request path starts with /source, respond with HTTP 403 Forbidden.

~~~
rewrite {
    regexp ^/source
    status 403
}
~~~

Rewrite /app to /index with a query string. {1} is the matched group (.*).

~~~
rewrite /app {
    r  (.*)
    to /index?path={1}
}
~~~
