Core functions
mod_core overview
mod_core module provides implementation of features that are
used in Helicon Ape as a whole.
Core directives
AccessFileName
| Description: |
Sets the name for distributed configuration file |
| Syntax: |
AccessFileName filename [filename] ... |
| Default: |
AccessFileName .htaccess |
| Context: |
server config, virtual host |
| Module: |
mod_core |
AccessFileName directive specifies a list of file names that
Helicon Ape will consider the names of distributed configurations. Default file
name is .htaccess. Helicon Ape will only load the first found
file in this list.
To protect configuration files starting from .ht the following piece
of code will be written in your httpd.conf upon installation:
<Files ~ ^.ht>
RewriteEngine on
RewriteRule . - [F]
</Files>
Note! If you are about to change default configuration file
name using AccessFileName directive, you'll need to write rules
to protect them manually.
When any changes are applied to the configuration file it will be reloaded
automatically upon the next request to the server.
AllowOverride
| Description: |
Explicitly sets the base URL for per-directory rewrites |
| Syntax: |
AllowOverride All|None|directive-type [directive-type]
... |
| Default: |
AllowOverride All |
| Context: |
server config, virtual host, directory |
| Module: |
mod_core |
AllowOverride directive declares which directives in distributed
.htaccess files can override parent level directives (httpd.conf).
This directive also enables or disables .htaccess files for specific
virtual host (web site) or directory.
The following values are supported:
- AuthConfig - allows to use authorization directives
(AuthGroupFile, AuthName, AuthType, AuthUserFile, Require, etc.).
- FileInfo - allows to use directives controlling
document types, document meta data, mod_rewrite directives (RewriteEngine,
RewriteOptions, RewriteBase, RewriteCond, RewriteRule).
- Indexes - allows to use directives controlling
directory indexing.
- Limit - allows to use directives controlling
host access (Allow, Deny and Order).
- Options[=Option,...] - allows to use directives
controlling specific directory features. An equal sign may be given followed
by a comma-separated lists of options that may be set using the Options command.
All value enables .htaccess file and all
directives in it. None disables all .htaccess files
and directives. This directive is inheritable. This means if you specify AllowOverride
none for some directory, .htaccess files will also be disabled
for all subdirectories.
Note! AllowOverride function has the default
value of All. AllowOverride None
is usually necessary only on high-load servers, when you need to stop processing
of .htaccess files inside specific locations:
AllowOverride none
<VirtualHost onesite.com www.onesite.com>
AllowOverride all
</VirtualHost>
AuthName
| Description: |
Sets authorization realm for use in HTTP authentication |
| Syntax: |
AuthName auth-domain |
| Context: |
directory, .htaccess |
| Module: |
mod_core |
AuthName directive sets the name of the authorization realm
for the directory. This realm is needed for the user to know which username
and password to send. AuthName has a single argument - auth-domain.
If the realm name contains spaces, it must be enclosed into quotation marks.
It must be accompanied by AuthType
and Require directives, and directives
such as AuthUserFile
and AuthGroupFile
to work.
Example:
AuthName "Secret"
The string set to AuthName will appear in the password dialog
provided by most browsers.
AuthType
| Description: |
Specifies the type of user authentication |
| Syntax: |
AuthType Basic|Digest |
| Context: |
directory, .htaccess |
| Module: |
mod_core |
AuthType directive allows to choose between Basic
and Digest authentication.
To implement authentication you must also use the AuthName
and Require directives. In addition,
the server must have an authentication-provider module such as mod_authn_file
and an authorization module such as mod_authz_user.
ErrorDocument
| Description: |
Defines what page will be shown to the client upon specific error |
| Syntax: |
ErrorDocument error-code document |
| Context: |
server config, virtual host, directory, .htaccess |
| Module: |
mod_core |
ErrorDocument directive defines the document that will be shown to the client upon error.
document parameter may be specified either relative to the document root (starting with slash) or as a full URL
(starting with protocol, domain name, etc.). Alternatively, you may ask a browser to display custom error description.
Example:
ErrorDocument 500 http://www.domain.com/cgi-bin/tester
ErrorDocument 404 /custom_error_page.htm
ErrorDocument 403 "Sorry, the access is forbidden"
Additionally, the special value "default" can be used to tell Ape use standard hardcoded message. Usually,
it's not necessary to specify this explicitly, unless you need different behavior in different contexts.
Example:
ErrorDocument 404 /cgi-bin/bad_urls.pl
<Directory /web/docs>
ErrorDocument 404 default
</Directory>
Note that when you specify an ErrorDocument that points to a remote URL (fully qualified path),
Ape will send a redirect to the client to tell it where to find the document,
even if the document ends up being on the same server. This implies that the client will not receive
the original error status code but instead will receive a redirect status code.
This in turn can confuse web robots and other clients which try to determine URL validity based on
the status code. In addition, if you use remote URL in ErrorDocument 401,
the client will not know whether to prompt the user for a password since it will not receive the 401 status code.
Therefore, if you use an ErrorDocument 401 directive, it must refer to a local document.
ErrorLog
| Description: |
Sets the location for server log file |
| Syntax: |
ErrorLog file-path|syslog[:facility] |
| Default: |
inside directory containing httpd.conf file |
| Context: |
server config, virtual host |
| Module: |
mod_core |
ErrorLog directive sets the name of the file to which the
server will log errors it encounters. If the file-path
is not absolute, it is assumed to be relative to the ServerRoot.
Example:
ErrorLog /logs/Ape_logs/error_log
FreeSites
| Description: |
Specifies IDs of the sites to apply free Ape licenses to |
| Syntax: |
FreeSites #id1 #id2 #id3 |
| Context: |
server config |
| Module: |
mod_core |
FreeSites directive is used to specify for which sites (up
to 3!) Ape free licenses will be applied.
id1, id2, id3 are the identifiers of the sites in IIS.
Example:
FreeSites #123 #456 #789
See also: RegistrationName, RegistrationCode
Include
| Description: |
Includes other configuration files from within the server configuration
files |
| Syntax: |
Include file-path|directory-path |
| Context: |
server config, virtual host, directory |
| Module: |
mod_core |
Include directive allows inclusion of other configuration
files from within the server configuration files. The file-path
specified may be an absolute path, or may be relative to the ServerRoot
directory.
Example:
Include /ape/conf/file.conf
Include conf/file.conf
LogLevel
| Description: |
Controls the verbosity of the ErrorLog |
| Syntax: |
ErrorLog file-path |
| Default: |
directory containing httpd.conf file |
| Context: |
server config, virtual host |
| Module: |
mod_core |
LogLevel directive adjusts the verbosity of the messages recorded
in the error logs. The following values are possible:
Level |
Description |
| none |
Log nothing |
| emerg |
Emergencies - system is unusable |
| alert |
Action must be taken immediately |
| crit |
Critical Conditions |
| error |
Error conditions |
| warn |
Warning conditions |
| notice |
Normal but significant condition |
| info |
Informational records |
| debug |
Debug-level messages |
Example:
LogLevel debug
Options
| Description: |
Configures what features are available in a particular directory |
| Syntax: |
Options [+|-]option [[+|-]option] ... |
| Default: |
Options All |
| Context: |
server config, virtual host, directory, .htaccess |
| Module: |
mod_core |
Options directive controls which server features are available in a particular directory.
option parameter may be set to None, in which case none of the extra features are enabled, or one or more of the following:
- All (default) - all supported options are enabled
- ExecCGI (currently not supported in Ape)
- FollowSymLinks (currently not supported in Ape)
- Includes (currently not supported in Ape)
- IncludesNOEXEC (currently not supported in Ape)
- Indexes (currently not supported in Ape)
- MultiViews (currently not supported in Ape)
- ShowErrorInResponse (not supported in Apache) - show detailed error explanation
This parameter allows to make error page more informative by adding detailed error description to the page.
By default, Ape will append explanation of all errors that occurred during
request processing to Ape error.log and to the browser error page.
Note! This parameter will take effect only when the Detailed Error option is
selected in IIS Manager -> Error Pages -> Edit Feature Settings...
Example:
#force Ape to append explanation of error(s) that occurred during request processing
#Note! We recommend to use this setting only for testing purposes
Options +ShowErrorInResponse
- StopOnError (not supported in Apache) -
regulates whether to ignore unknown directives or give out 500 error
This parameter regulates whether Helicon Ape should ignore unknown directives in its configs
or give out the 500 error.
By default, having found the syntax error in config Ape will stop request
processing.
Note! This parameter will take effect only when the Detailed Error option is
selected in IIS Manager -> Error Pages -> Edit Feature Settings...
Example:
#force Ape to ignore syntax errors in config
#Attention! We do not recommend to use this setting as it leads to unnoticed typos
Options -StopOnError
- SymLinksIfOwnerMatch (currently not supported in Ape)
RegistrationCode
| Description: |
Contains registration code for Ape |
| Syntax: |
RegistrationCode= code |
| Context: |
server config, virtual host, directory, .htaccess |
| Module: |
mod_core |
RegistrationCode directive is used to specify Ape
registration code for the specific content.
Note! RegistrationCode and RegistrationName directives
enable Ape for the context they are located in.
Example:
RegistrationCode= 11111-22222-33333-44444
See also: RegistrationName, FreeSites
RegistrationName
| Description: |
Contains registration name for Ape |
| Syntax: |
RegistrationName= name |
| Context: |
server config, virtual host, directory, .htaccess |
| Module: |
mod_core |
RegistrationName directive is used to specify Ape
registration name for the specific content.
Note! RegistrationCode and RegistrationName directives
enable Ape for the context they are located in.
Example:
RegistrationName MyName
See also: RegistrationCode, FreeSites
Require
| Description: |
Selects which authenticated users can access a resource |
| Syntax: |
Require entity-name [entity-name] ... |
| Context: |
directory, .htaccess |
| Module: |
mod_core |
Require directive selects which authenticated users can access
a resource. The restrictions are processed by authorization modules.
Example:
#Only named users can access the resource
Require user userid1 userid2
#Only users in the named groups can access the resource
Require group groupname1 groupname2
#All valid users can access the resource
Require valid-user
Satisfy
| Description: |
Interaction between host-level access control and user authentication |
| Syntax: |
Satisfy Any|All |
| Default: |
Satisfy All |
| Context: |
directory, .htaccess |
| Module: |
mod_core |
Satisfy directive defines access policy if both Allow
and Require directives are used (i.e.
a particular area is restricted by both username/password and client host address).
Values:
- All (default) - both correct address and valid
username/password are required.
- Any - either correct address or valid username/password
is sufficient to be granted access.
Example:
Require valid-user
Allow from 192.168.1
Satisfy Any
SetOutputFilter
| Description: |
Sets the output filter for specified filter definition |
| Syntax: |
SetOutputFilter name [;name] |
| Context: |
server config, virtual host, directory, .htaccess |
| Module: |
mod_core |
SetOutputFilter directive activates the name filter. If there are multiple filters to activate, semicolons must be put between the names.
Example:
SetOutputFilter gzip;hotlink;linkfreeze;<mod_replace>;<mod_filter>
Note! mod_replace and mod_filter do not have predefined filter names; they shall be specified
explicitly (see corresponding docs articles).
<Directory>
| Description: |
Groups directives that will be applied to specific file-system directory
and sub-directories |
| Syntax: |
<Directory directory-path> ... </Directory> |
| Context: |
server config, virtual host |
| Module: |
mod_core |
<Directory> ... </Directory> tag is used to group
directives that will be applied to the specific file system directory and sub-directories.
Wildcard characters ? and * are allowed. Regular expressions can also be used
with prepended ~ character.
Be careful with directory-path arguments: They have to literally match the
file system path which is used to access files. Directives applied to the particular
<Directory> will not be applied to files accessed from
that directory via a different path, i.e. via different symbolic links. Only
fully qualified file paths are allowed.
Example:
<Directory C:/inetpub/>
AllowOverride None
</Directory>
<Directory C:/inetpub/home/>
AllowOverride FileInfo
</Directory>
<Directory ~ "C:/inetpub/wwwroot/.*/[0-9]{3}">
# ... directives here ...
</Directory>
<DirectoryMatch>
| Description: |
Groups directives that will be applied to specific file-system directory
and sub-directories |
| Syntax: |
<DirectoryMatch regex> ... </DirectoryMatch> |
| Context: |
server config, virtual host |
| Module: |
mod_core |
<DirectoryMatch> ... </DirectoryMatch> is used
to enclose a group of directives which will be applied only to the specified
file system directory and its sub-directories. This directive works exactly
as <Directory ~>.
Example:
<DirectoryMatch "^/www/(.+/)?[0-9]{3}">
# ... directives here ...
</DirectoryMatch>
<Files>
| Description: |
Encloses directives that will be applied to matched filenames |
| Syntax: |
<Files filename> ... </Files> |
| Context: |
server config, virtual host, directory, .htaccess |
| Module: |
mod_core |
<Files> directive limits the scope of enclosed directives
by filename. The filename argument should include a filename, it supports
? and * wildcards and regular expressions with prepended ~ character.
Example:
<Files index.*>
# ... directives here ...
</Files>
<Files ~ "\.(gif|jpe?g|png)$">
# ... directives here ...
</Files>
<FilesMatch>
| Description: |
Encloses directives that will be applied to matched filenames |
| Syntax: |
<FilesMatch regex> ... </FilesMatch> |
| Context: |
server config, virtual host, directory, .htaccess |
| Module: |
mod_core |
<FilesMatch> directive does exactly the same as <Files
~>.
Example:
<FilesMatch "\.(gif|jpe?g|png)$">
<IfModule>
| Description: |
Encloses directives that are processed depending on the presence or absence
of a specific module |
| Syntax: |
<IfModule [!]module-file|module-identifier> ... </IfModule> |
| Context: |
server config, virtual host, directory, .htaccess |
| Module: |
mod_core |
<IfModule> section is used to mark directives that are
dependant on the presence of a specific module.
The test in <IfModule> section may be performed in two
ways:
module
!module
In the first case the directives will only be processed if the module named
module is included in Helicon Ape. The second case implies the reverse
situation and processes the directives only if module is not included.
<Limit>
| Description: |
Restricts enclosed access controls to only certain HTTP methods |
| Syntax: |
<Limit method [method] ... > ... </Limit> |
| Context: |
server config, virtual host, directory, .htaccess |
| Module: |
mod_core |
<Limit> section allows to restrict the effect of the
access controls to the nominated HTTP methods.
Methods include: GET, POST, PUT, DELETE, CONNECT, OPTIONS, PATCH, PROPFIND,
PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK and more.
Note! The method name is case-sensitive.
Note! If GET is used, HEAD requests will also
be restricted. The TRACE method cannot be limited.
Example:
<Limit POST PUT DELETE>
Require valid-user
</Limit>
<LimitExcept>
| Description: |
Restricts access controls to all HTTP methods except the named ones |
| Syntax: |
<LimitExcept method [method] ... > ... </LimitExcept> |
| Context: |
server config, virtual host, directory, .htaccess |
| Module: |
mod_core |
<LimitExcept> section is used to enclose a group of
access control directives which will be applied to any HTTP access method not
listed in the arguments. This directive has reverse effect to <Limit>
directive.
Example:
<LimitExcept POST GET>
Require valid-user
</LimitExcept>
<Location>
| Description: |
Applies the enclosed directives only to matching URL or virtual path |
| Syntax: |
<Location URL-path|URL> ... </Location> |
| Context: |
server config, virtual host |
| Module: |
mod_core |
<Location> ... </Location> tag is used to group
directives that will apply to specific URL or virtual path. <Location>
sections operate completely outside the file system thus these directives should
not be used to control access to file system locations since several different
URLs may map to the same file system location.
The URL-path is a virtual path in the form /path/. Protocol, hostname,
port and query string may be lacking. URL-path may include wildcards
? and * or regular expression starting with ~ character.
Example:
<Location /directory>
# ... rules go here
</Location>
<Location />
# ... more rules go here
</Location>
<LocationMatch>
| Description: |
Applies the enclosed directives only to regular-expression matching URLs |
| Syntax: |
<LocationMatch regex> ... </LocationMatch> |
| Context: |
server config, virtual host |
| Module: |
mod_core |
<LocationMatch> directive does exactly the same as <Location
~>.
Example:
<LocationMatch "/(home|section)/bin">
# ... rules go here
</LocationMatch>
<Proxy>
| Description: |
Container for directives applied to proxied resources |
| Syntax: |
<Proxy wildcard-url> ...</Proxy> |
| Context: |
server config, virtual host |
| Module: |
mod_core |
<Proxy> section may include directives that will apply
only to matching proxied content. Wildcards are possible.
Note! mod_proxy is
required to make <Proxy> directive working.
Example:
Below is an example to allow hosts only from somenet.example.com access
content via your proxy server:
<Proxy *>
Order deny,allow
Deny from all
Allow from somenet.example.com
</Proxy>
Example:
Here's an example to process all files in foo directory of example.com
through the INCLUDES filter when they are sent through proxy server:
<Proxy http://example.com/foo/*>
SetOutputFilter INCLUDES
</Proxy>
<ProxyMatch>
| Description: |
Container for directives applied to regular-expression-matched proxied
resources |
| Syntax: |
<ProxyMatch regex> ...</ProxyMatch> |
| Context: |
server config, virtual host |
| Module: |
mod_core |
<ProxyMatch> directive is identical to <Proxy>
directive, except that it matches URLs using regular expressions.
<VirtualHost>
| Description: |
Groups directives that will be applied to specific IP address or host
name |
| Syntax: |
<VirtualHost addr[:port] [addr[:port]] ...> ...
</VirtualHost> |
| Context: |
server config |
| Module: |
mod_core |
<VirtualHost> ... </VirtualHost> tag is used to
group directives that will be applied to the specific virtual host.
Possible values for addr value are:
- Specific IP address;
- Fully qualified domain name;
- The string _default_, which will match all unattended requests.
Example:
RewriteEngine off
AllowOverride none
<VirtualHost onesite.com www.onesite.com>
RewriteEngine on
AllowOverride all
</VirtualHost>
