Apache is the most popular webserver in the world. It works on a great number of servers and more than half of the websites on the internet are executed with the help of Apache. It can handle the needs of both large and small projects.

Apache includes a basic core intended mainly for processing HTTP requests. The vast majority of numerous additional functions are available thanks to additional modules (or 'mods').

Each Apache server requires modules for its performance. The modules allow for Apache to make URL rewriting to SSL encryption natively, for example:

Each module is required for one or another activity. For example, the most popular module mod_rewrite is responsible for redirect rules such as redirection from HTTP to HTTPS protocol. Detailed explanation on how you can set up redirection can be found here. You will find a brief explanation of every module installed on our servers below in the table.

Below is the list of Apache modules installed on our Shared servers. The major part of modules will be similar for Stellar, Stellar Plus and Stellar Business plans (and old Value, Professional, Ultimate and Business hosting packages). The only difference is that mod_lsapi and cgid modules exist in Stellar, Stellar Plus and old Value, Professional and Ultimate packages and absent on Stellar Business and old Business SSD plans. And fakephp, cgi and fcgi are installed on Business servers only.

As you may see from the table above, some of the modules come with static and other with shared annex. Static module will be loaded every time Apache is started. Shared is not loaded on the start of Apache and you can choose whether you want to load it or not.

Below you will find description of each module:

actions_module: this module provides executing CGI scripts based on media type or request method. The module has two directives. The Action directive lets you run CGI scripts whenever a file of a certain MIME content type is requested. The Script directive lets you run CGI scripts whenever a particular method is used in a request. This makes it much easier to execute scripts that process files.

alias_module: provides mapping of different parts of the host filesystem in the document tree and for URL redirection. The directives contained in this module allow manipulation and control of URLs as requests arrive at the server.

The Alias and ScriptAlias directives are used to map between URLs and filesystem paths. This allows for content which is not directly under the DocumentRoot served as part of the web document tree. The ScriptAlias directive has the additional effect of marking the target directory as containing only CGI scripts. The Redirect directives are used to instruct clients to make a new request with a different URL. They are often used when a resource has moved to a new location. mod_alias is designed to handle simple URL manipulation tasks. For more complicated tasks such as manipulating the query string, use the tools provided by mod_rewrite.

asis_module: sends files that contain their own HTTP headers. This module provides the handler send-as-is which causes Apache to send the document without adding most of the usual HTTP headers. This can be used to send any kind of data from the server, including redirects and other special HTTP responses, without requiring a cgi-script or an nph script.

auth_basic_module: this module allows the use of HTTP Basic Authentication to restrict access by looking up users in the given providers. HTTP Digest Authentication is provided by mod_auth_digest. This module should usually be combined with at least one authentication module such as mod_authn_file and one authorization module such as mod_authz_user.

auth_digest_module: user authentication using MD5 Digest Authentication. This module implements HTTP Digest Authentication and provides an alternative to mod_auth_basic where the password is not transmitted as cleartext. However, this does not lead to a significant security advantage over basic authentication. On the other hand, the password storage on the server is much less secure with digest authentication than with basic authentication. Therefore, using basic auth and encrypting the whole connection using mod_ssl is a much better alternative.

authn_anon_module: allows 'anonymous' user access to authenticated areas. This module provides authentication front-ends such as mod_auth_basic to authenticate users similar to anonymous-ftp sites, i.e. have a 'magic' user id 'anonymous' and the email address as a password. These email addresses can be logged. Combined with other (database) access control methods, this allows for effective user tracking and customization according to a user profile while still keeping the site open for 'unregistered' users. One advantage of using Auth-based user tracking is that unlike magic-cookies and funny URL pre/postfixes, it is completely browser independent and allows users to share URLs.

authn_dbm_module: user authentication using DBM files. This module provides authentication front-ends such as mod_auth_digest and mod_auth_basic to authenticate users by looking up users in dbm password files. Similar functionality is provided by mod_authn_file which is explained above.

authn_default_module: authentication fallback module. This module is designed to be the fallback module, if you don't have configured an authentication module like mod_auth_basic. It simply rejects any credentials supplied by the user.

authn_file_module: user authentication using text files. Acts as an authentication provider to other modules, like mod_auth_basic and mod_auth_digest, by checking users against plaintext password files. Similar functionality is provided by mod_authn_dbm.

authz_default_module: this module is designed to be the fallback module, if you don't have configured an authorization module like mod_authz_user or mod_authz_groupfile. It simply rejects any authorization request.

authz_groupfile_module: group authorization using plaintext files. This module provides authorization capabilities so that authenticated users can be allowed or denied access to portions of the web site by group membership. Similar functionality is provided by mod_authz_dbm.

authz_host_module: group authorizations based on host (name or IP address). The directives provided by mod_authz_host are used in Directory, Files, and Location sections as well as .htaccess files to control access to particular parts of the server. Access can be controlled based on the client hostname, IP address, or other characteristics of the client request, as captured in environment variables. The Allow and Deny directives are used to specify which clients are or are not allowed access to the server, while the Order directive sets the default access state, and configures how the Allow and Deny directives interact with each other.

authz_user_module: this module provides authorization capabilities so that authenticated users can be allowed or denied access to portions of the website. mod_authz_user grants access if the authenticated user is listed in a Require user directive. Alternatively Require valid-user can be used to grant access to all successfully authenticated users.

autoindex_module: generates directory indexes, automatically, similar to the Unix ls command or the Win32 dir shell command.

bw_module: an Apache module provided to solve the problem of limiting users’ and virtual hosts’ bandwidth usage.

bwlimited_module: bandwidth limiter module allows Apache web server to control over resources for each its virtual hosts. The module is an output filter in the Apache filters chain; each time a user requests data from the web server, the data (response) has to go through the module.

The module breaks the data into smaller pieces and sends the pieces. And controls the bandwidth by introducing a small delay while sending the pieces. Looking at the module characteristics, the module is useful to limit access to predefined areas of the website and protect the web server from malicious users.

cache_module: content cache keyed to URIs. This module works via HTTP-based caching schemes. It means that the files will be cached due to an instruction which shows the time a page should be considered 'new'.

cgi_module: execution of CGI scripts. Any file that has the handler cgi-script will be treated as a CGI script, and run by the server, with its output being returned to the client. Files acquire this handler either by having a name containing an extension defined by the AddHandler directive, or by being in a ScriptAlias directory.

cgid_module: execution of CGI scripts using an external CGI daemon. Except for the optimizations and the additional ScriptSock directive noted below, mod_cgid behaves similarly to mod_cgi.

charset_lite_module: specifies character set translation or recoding. mod_charset_lite allows the server to change the character set of responses before sending them to the client.

core_module: this module is the central one for HTTP web server. It provides core Apache HTTP Server features that are always available. It has such directives as AllowOverride, DocumentRoot, Files, IfModule, Limit, LimitRequestBody, VirtualHost etc. Configures optimizations for a Protocol's Listener Sockets.

dav_fs_module: this module requires the service of mod_dav. It acts as a support module for mod_dav and provides access to resources located in the server's file system. The formal name of this provider is filesystem. mod_dav backend providers will be invoked by using the Dav directive: Dav filesystem.

dav_module: Distributed Authoring and Versioning (WebDAV) functionality. This module provides class 1 and class 2 WebDAV ('Web-based Distributed Authoring and Versioning') functionality for Apache. This extension to the HTTP protocol allows creating, moving, copying, and deleting resources and collections on a remote web server.

deflate_module: compresses content before it is delivered to the client. The mod_deflate module provides the deflate output filter that allows output from your server to be compressed before being sent to the client over the network.

dir_module: provides 'trailing slash' redirects and serving directory index files.

env_module: modifies the environment which is passed to CGI scripts and SSI pages. This module allows the control of internal environment variables that are used by various Apache HTTP Server modules. These variables are also provided to CGI scripts as native system environment variables, and available for use in SSI pages.

expires_module: this module controls the setting of the Expires HTTP header and the max-age directive of the Cache-Control HTTP header in server responses. The expiration date can set to be relative to either the time the source file was last modified, or to the time of the client access. These HTTP headers are an instruction to the client about the document's validity and persistence. If cached, the document may be fetched from the cache rather than from the source until this time has passed. After that, the cache copy is considered ‘expired’ and invalid, and a new copy must be obtained from the source.

fakephp_module: this module helps to ignore such directives from FastCGI as php_admin_value, php_admin_flag, php_value, php_flag.

fastinclude_module: general Apache module included in each server configuration.

fcgid_module: provides for execution of FastCGI applications. Any program assigned to the handler fcgid-script is processed using the FastCGI protocol; mod_fcgid starts a sufficient number instances of the program to handle concurrent requests, and these programs remain running to handle further incoming requests. This is significantly faster than using the default mod_cgi or mod_cgid modules to launch the program upon each request. However, the programs invoked by mod_fcgid continue to consume resources, so the administrator must weigh the impact of invoking a particular program once per request against the resources required to leave a sufficient number of instances running continuously.

filter_module: context-sensitive smart filter configuration module. This module enables smart, context-sensitive configuration of output content filters. For example, Apache can be configured to process different content-types through different filters, even when the content-type is not known in advance (e.g. in a proxy).

headers_module: customization of HTTP request and response headers. This module provides directives to control and modify HTTP request and response headers. Headers can be merged, replaced or removed.

hostinglimits_module: a third-party module for CloudLinux™. Works with existing cgi/php modules, to put them into LVE context. In most cases the cgi/php process will be placed into Lightweight Virtual Environment (LVE) with ID of user that sites belongs to. mod_hostinglimits detects the user from SuexecUserGroup (suexec module), AssignUserID (MPM ITK), RUidGid (mod_ruid2) directives.

http_module: general Apache module which is required for HTTP protocol performance and HTTP traffic.

include_module: server-parsed HTML documents. This module provides a filter which will process files before they are sent to the client. The processing is controlled by specially formatted SGML comments, referred to as elements. These elements allow conditional text, the inclusion of other files or programs, as well as the setting and printing of environment variables.

log_config_module: logging of the requests made to the server. This module provides a flexible logging of client requests. Logs are written in a customizable format and may be written directly to a file, or to an external program. Conditional logging is provided so that individual requests may be included or excluded from the logs based on characteristics of the request.

logio_module: logging of input and output bytes per request. This module provides the logging of input and output number of bytes received/sent per request. The numbers reflect the actual bytes as received on the network, which then takes into account the headers and bodies of requests and responses. The counting is done before SSL/TLS on input and after SSL/TLS on output, so the numbers will correctly reflect any changes made by encryption. This module requires mod_log_config.

mime_magic_module: determines the MIME type of a file by looking at a few bytes of its contents. This module determines the MIME type of files in the same way the Unix file command works: it looks at the first few bytes of the file. It is intended as a 'second line of defense' for cases that mod_mime can't resolve.

mime_module: associates the requested filename's extensions with the file's behavior (handlers and filters) and content (mime-type, language, character set and encoding). This module is used to associate various bits of ‘meta information’ with files by their filename extensions. This information relates the filename of the document to its mime-type, language, character set, and encoding. This information is sent to the browser and participates in content negotiation, so the user's preferences are respected when choosing one of several possible files to serve.

mod_lsapi: Apache mod_lsapi is a module based on LiteSpeed Technologies API for PHP, Ruby and Python. It offers excellent PHP performance, low memory footprint coupled with great security and support for opcode caching.

mpm_prefork_module: Multi-Processing Module (MPM) implements a non-threaded, pre-forking web server. Each server process may answer incoming requests, and a parent process manages the size of the server pool. It is appropriate for sites that need to avoid threading for compatibility with non-thread-safe libraries. It is also the best MPM for isolating each request so that a problem with a single request will not affect any other. This MPM is very self-regulating, so it is rarely necessary to adjust its configuration directives. A single control process is responsible for launching child processes which listen for connections and serve them when they arrive. Apache httpd always tries to maintain several spare or idle server processes, which stand ready to serve incoming requests. In this way, clients do not need to wait for a new child process to be forked before their requests can be served.

mpm_worker_module: Multi-Processing Module (MPM) implements a hybrid multi-process multi-threaded server. By using threads to serve requests, it is able to serve a large number of requests with fewer system resources than a process-based server. However, it retains much of the stability of a process-based server by keeping multiple processes available, each with many threads.

negotiation_module: content negotiation, or more accurately content selection, is the selection of the document that best matches the clients capabilities, from one of several available documents.

proxy_ajp_module: this module requires the service of mod_proxy. It provides support for the Apache JServ Protocol version 1.3 (hereafter AJP13).

proxy_balancer_module: requires the service of mod_proxy. It provides load balancing support for HTTP, FTP and AJP13 protocols.

proxy_connect_module: requires the service of mod_proxy. It provides support for the CONNECT HTTP method. This method is mainly used to tunnel SSL requests through proxy servers.

proxy_ftp_module: this module requires the service of mod_proxy. It provides support for the proxying FTP sites.

proxy_http_module: requires the service of mod_proxy. It provides the features used for proxying HTTP and HTTPS requests.

mod_proxy_http supports HTTP/0.9, HTTP/1.0 and HTTP/1.1. It does not provide any caching abilities.

proxy_module: implements a proxy/gateway for Apache. It implements proxying capability for AJP13 (Apache JServe Protocol version 1.3), FTP, CONNECT (for SSL), HTTP/0.9, HTTP/1.0, and HTTP/1.1. The module can be configured to connect to other proxy modules for these and other protocols.

proxy_scgi_module: this module requires the service of mod_proxy. It provides support for the SCGI protocol, version 1.

rewrite_module: provides a rule-based rewriting engine to rewrite requested URLs on the fly. By default, mod_rewrite maps a URL to a filesystem path. However, it can also be used to redirect one URL to another URL, or to invoke an internal proxy fetch.

mod_rewrite provides a flexible and powerful way to manipulate URLs using an unlimited number of rules. Each rule can have an unlimited number of attached rule conditions, to allow you to rewrite URL based on server variables, environment variables, HTTP headers, or time stamps.

mod_rewrite operates on the full URL path, including the path-info section. A rewrite rule can be invoked in httpd.conf or in htaccess. The path generated by a rewrite rule can include a query string, or can lead to internal sub-processing, external request redirection, or internal proxy throughput.

rpaf_module: if you check the Apache access log files you should see that all incoming requests are coming from 127.0.0.1. To fix this you need to install mod_rpaf, the reverse proxy add forward module for Apache.

security2_module: ModSecurity is one of Apache server modules that provides a complete website protection by defending hackers and other malicious attacks. It is a set of rules with regular expressions that helps to instantly ex-filtrate the commonly known exploits. ModSecurity obstructs the processing of invalid data (code injection attacks) to reinforce and nourish the server's security.

setenvif_module: mod_setenvif allows you to set internal environment variables according to whether different aspects of the request match regular expressions you specify. These environment variables can be used by other parts of the server to make decisions about actions to be taken, as well as becoming available to CGI scripts and SSI pages.

so_module: loading of executable code and modules into the server at start-up or restart time. On selected operating systems this module can be used to load modules into Apache at runtime via the Dynamic Shared Object (DSO) mechanism, rather than requiring a recompilation.

On Unix, the loaded code typically comes from shared object files (usually with .so extension), on Windows this may either .so or .dll extension.

ssl_module: strong cryptography using the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. This module provides SSL v2/v3 and TLS v1 support for the Apache HTTP Server. It was contributed by Ralf S. Engeschall based on his mod_ssl project and originally derived from work by Ben Laurie. This module relies on OpenSSL to provide the cryptography engine.

status_module: provides information on server activity and performance. The Status module allows a server administrator to find out how well their server is performing. An HTML page is presented that gives the current server statistics in an easily readable form. If required this page can be made to automatically refresh (given a compatible browser). Another page gives a simple machine-readable list of the current server state.

suexec_module: allows CGI scripts to run as a specified user and Group.

unique_id_module: this module provides a magic token for each request which is guaranteed to be unique across 'all' requests under very specific conditions. The unique identifier is even unique across multiple machines in a properly configured cluster of machines. The environment variable UNIQUE_ID is set to the identifier for each request. Unique identifiers are useful for various reasons which are beyond the scope of this article.

userdir_module: this module allows user-specific directories to be accessed using http://example.com/~user/ syntax. It is disabled on our shared servers due to security reasons, however,  you can use it with our VPS/Dedicated server plans.

version_module: this module is designed for the use in test suites and large networks which have to deal with different httpd versions and different configurations. It provides a new container -- IfVersion, which allows a flexible version checking including numeric comparisons and regular expressions.

As you may see from the table above, some of the modules come with static and other with shared annex. The static module will be loaded every time Apache is started. Shared is not loaded on the start of Apache and you can choose whether you want to load it or not.

A single control process is responsible for launching child processes which listen for connections and serve them when they arrive. Apache httpd always tries to maintain several spare or idle server processes, which stand ready to serve incoming requests. In this way, clients do not need to wait for a new child process to be forked before their requests can be served.

As a conclusion it should be clarified that all the modules are installed on the servers and working properly.


That's it!

Need any help? Contact our HelpDesk