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>
	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: 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.

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

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: inside 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
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

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

StopOnError

Description: Regulates whether to ignore unknown directives of give 500 error
Syntax: StopOnError On|Off
Default: StopOnError Off
Context: directory, .htaccess
Module: mod_core

StopOnError directive regulates whether Helicon Ape should ignore unknown directives in its configs or give out the 500 error.

Values:

  • Off (default) - ignore unknown directives.
  • On - give out 500 error for unknown directives.

<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_proxy

<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_proxy

<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>