ProFTPD module mod_rewrite

This module is contained in the mod_rewrite.c file for ProFTPD 1.3.x, and is not compiled by default. Installation instructions are discussed here.

The most current version of mod_rewrite is distributed with the ProFTPD source code.

A discussion of the usage of this module follows.


Please contact TJ Saunders <tj at> with any questions, concerns, or suggestions regarding this module.



Syntax: RewriteCondition condition pattern [flags]
Default: None
Context: server config, <VirtualHost>, <Global>, <Anonymous>, <Directory>
Module: mod_rewrite
Compatibility: 1.2.6rc1 and later

The RewriteCondition directive defines a rule condition. Precede a RewriteRule directive with one or more RewriteCondition directives. The following rewriting rule is only used if its pattern matches the current state of the FTP command and if these additional conditions apply too.

Condition is a string which can contain the following expanded constructs in addition to plain text:

Pattern is the condition pattern, i.e., a regular expression which is applied to the current instance of the condition, i.e., condition is evaluated and then matched against pattern. You can prefix the pattern string with a '!' character (exclamation mark) to specify a non-matching pattern.

The pattern can also be one of these special variants:

Notice: All of these variants can also be prefixed by an exclamation mark ('!') to negate their meaning.

Flags, if present, modify how this RewriteCondition is evaluated. Supported flags are:


Syntax: RewriteEngine on|off
Default: off
Context: server config, <VirtualHost>, <Global>
Module: mod_rewrite
Compatibility: 1.2.6rc1 and later

The RewriteEngine directive enables or disables the module's runtime rewriting engine. If it is set to off this module does no parsing or rewriting at all. Use this directive to disable the module instead of commenting out all mod_rewrite directives.


Syntax: RewriteLock file
Default: None
Context: server config, <VirtualHost>, <Global>
Module: mod_rewrite
Compatibility: 1.2.6rc1 and later

The RewriteLock directive sets the filename for a synchronization lockfile which mod_rewrite needs to communicate with RewriteMaps of type fifo. Set file to a local absolute path (not on a NFS-mounted device) when you want to use a rewriting FIFO. It is not required for other types of rewriting maps.


Syntax: RewriteLog file|"none"
Default: None
Context: server config, <VirtualHost>, <Global>
Module: mod_rewrite
Compatibility: 1.2.6rc1 and later

The RewriteLog directive is used to specify a log file for mod_rewrite reporting and debugging, and can be done a per-server basis. The file parameter must be the full path to the file to use for logging. Note that this path must not be to a world-writeable directory and, unless AllowLogSymlinks is explicitly set to on (generally a bad idea), the path must not be a symbolic link. In general, this directive should only be used for debugging your mod_rewrite configuration, and should be removed once debugging is completed; do not use this directive in a production configuration.

If file is "none", no logging will be done at all; this setting can be used to override a RewriteLog setting inherited from a <Global> context.


Syntax: RewriteMap map-name map-type:map-source
Default: None
Context: server config, <VirtualHost>, <Global>
Module: mod_rewrite
Compatibility: 1.2.6rc1 and later

The RewriteMap directive defines a rewriting map which can be used inside rule substitution strings by the mapping-functions to insert/substitute fields through a key lookup. The source of this lookup can be of various types.

The map-name is the name of the map and will be used to specify a mapping-function for the substitution strings of a rewriting rule via one of the following constructs:

${ map-name : lookup-key }
${ map-name : lookup-key | default-value}
When such a construct occurs the map map-name is consulted and the key lookup-key is resolved. If the key is found, the map-function construct is substituted by subst-value. If the key is not found then it is substituted by default-value or by the empty string if no default-value was specified.

The following combinations for map-type and map-src can be used:

The RewriteMap directive can occur more than once. For each mapping-function use one RewriteMap directive to declare its rewriting map name.

Note: For plain text files the looked-up keys are cached in-core until the mtime of the text map file changes or the server does a restart. This way you can have map-functions in rules which are used for every request. This is no problem, because the parsing of the text files only happens once!


Syntax: RewriteMaxReplace count
Default: 8
Context: server config, <VirtualHost>, <Global>
Module: mod_rewrite
Compatibility: 1.3.5rc1 and later

The RewriteMaxReplace directive is used to increase the number of replacements/substitutions that mod_rewrite will perform, when rewriting commands. By default, mod_rewrite will only replace up to 8 occurrences of a pattern in the input string; if there are more than 8 replacement occurrences, then the input string will be unchanged. If your input strings happen to have more than 8 occurrences to be replaced, you can use the RewriteMaxReplace to increase that limit.

For example, to increase the limit to 32 occurrences to be replaced, use:

  RewriteMaxReplace 32


Syntax: RewriteRule pattern substitution [flags]
Default: None
Context: server config, <VirtualHost>, <Global>, <Anonymous>, <Directory>
Module: mod_rewrite
Compatibility: 1.2.6rc1 and later

The RewriteRule directive is the real rewriting workhorse. The configuration directive can occur more than once. Each directive defines a single rewriting rule. The order of definition of these rules is important, because this order is used when applying the rules at run-time.

Note that each RewriteRule must be preceded by one (or more) RewriteCondition directive.

Pattern can be POSIX regular expression which gets applied to the current FTP command argument(s).

Some hints about the syntax of regular expressions:

For more information about regular expressions have a look at your local regex(3) manpage. If you are interested in more detailed information about regular expressions and their variants (POSIX regex, Perl regex, etc.) have a look at the following dedicated book on this topic:

Mastering Regular Expressions
Jeffrey E.F. Friedl
Nutshell Handbook Series
O'Reilly & Associates, Inc. 1997
ISBN 1-56592-257-3

Additionally in mod_rewrite the NOT character ('!') is a possible pattern prefix. This gives you the ability to negate a pattern; to say, for instance: "if the current argument(s) does NOT match this pattern". This can be used for exceptional cases, where it is easier to match the negative pattern, or as a last default rule.

Notice: When using the NOT character to negate a pattern you cannot have grouped wildcard parts in the pattern. This is impossible because when the pattern does NOT match, there are no contents for the groups. In consequence, if negated patterns are used, you cannot use $N in the substitution string.

Substitution of a rewriting rule is the string which is substituted for (or replaces) the original argument(s) for which pattern matched. Beside plain text you can use:

  1. $N backreferences to the RewriteRule pattern
  2. %N backreferences to the last matched RewriteCondition pattern
  3. variables as in RewriteCondition test strings
  4. map function calls (${map-name:lookup-key|default-value})
  5. environment variable substitutions (%{ENV:variable-name})
Backreferences are $N (N=0..9) identifiers which will be replaced by the contents of the Nth group of the matched pattern. The variables are the same as for the condition of a RewriteCondition directive, with two additions:
   %P   process ID
   %t   Unix time since the epoch, in seconds
The map functions come from the RewriteMap directive and are explained there. These four types of variables are expanded in the order of the above list.

All of the rewriting rules are applied to substitution. The command argument(s) is completely replaced by the substitution.

Flags, if present, modify how this RewriteRule is evaluated. Supported flags are:


The mod_rewrite's regular expressions are POSIX extended regular expressions, not Perl regular expressions. This can catch the unsuspecting admin unawares, especially if they are used to Perl.

When processing a RewriteRule, the mod_rewrite engine will first execute the RewriteRule's regular expression against the command parameters. If that expression fails, the RewriteRule is skipped. Any RewriteConditions that are attached to the rule are processed only if the rule's expression matches first.

One of the consequences is that the rewritten path may run afoul of any configured AllowFilter, DenyFilter, PathAllowFilter, or PathDenyFilter directives, causing unexpected or unwanted transfers. Please keep this in mind when configuring RewriteRules.

Some metas are not available at certain times (e.g. %U/%u for USER/PASS commands, etc)...

The following example configuration shows how to configure mod_rewrite so that all files uploaded to the server will have all-uppercase filenames:

  <IfModule mod_rewrite.c>
    RewriteEngine on

    # Have a log for double-checking any errors
    RewriteLog /var/log/ftpd/rewrite.log

    # Define a map that uses the internal "toupper" function
    RewriteMap uppercase int:toupper

    # Make the file names used by STOR be in all uppercase
    RewriteCondition %m STOR

    # Apply the map to the command parameters
    RewriteRule ^(.*) ${uppercase:$1}

This example shows how to convert all spaces in uploaded file names to underscores:
  <IfModule mod_rewrite.c>
    RewriteEngine on
    RewriteLog /var/log/ftpd/rewrite.log

    # Define a map that uses the internal "replaceall" function
    RewriteMap replace int:replaceall

    # We only want to use this rule on STOR commands
    RewriteCondition %m STOR

    # Apply the map to the command parameters
    RewriteRule ^(.*) "${replace:/$1/ /_}"



To install mod_rewrite, follow the usual steps for using third-party modules in ProFTPD:
  $ ./configure --with-modules=mod_rewrite
To build mod_rewrite as a DSO module:
  $ ./configure --enable-dso --with-shared=mod_rewrite
Then follow the usual steps:
  $ make 
  $ make install

Alternatively, if your proftpd was compiled with DSO support, you can use the prxs tool to build mod_rewrite as a shared module:

  $ prxs -c -i -d mod_rewrite.c

The mod_rewrite module supports trace logging, via the module-specific log channels:

Thus for trace logging, to aid in debugging, you would use the following in your proftpd.conf:
  TraceLog /path/to/ftpd/trace.log
  Trace rewrite:20
This trace logging can generate large files; it is intended for debugging use only, and should be removed from any production configuration.

© Copyright 2000-2023 TJ Saunders
All Rights Reserved