From 359ae809b83a85f843bc3a7149af4ee0fd1e61c2 Mon Sep 17 00:00:00 2001 From: brian Date: Thu, 21 Nov 1996 08:16:33 +0000 Subject: [PATCH] Moved core.html and modules.html to appropriate places in mod/ git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@76997 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/mod/core.html | 946 +++++++++++++++++++++++++++++++++++++ docs/manual/mod/index.html | 78 +++ 2 files changed, 1024 insertions(+) create mode 100644 docs/manual/mod/core.html create mode 100644 docs/manual/mod/index.html diff --git a/docs/manual/mod/core.html b/docs/manual/mod/core.html new file mode 100644 index 0000000000..c7225d732b --- /dev/null +++ b/docs/manual/mod/core.html @@ -0,0 +1,946 @@ + + + + +Apache Core Features + + + + + +

Apache Core Features

+ +These configuration parameters control the core Apache features, and are +always available. + + + +
+ + +

AccessConfig directive

+ +Syntax: AccessConfig filename
+Default: AccessConfig conf/access.conf
+Context: server config, virtual host
+Status: core

+ +The server will read this file for more directives after reading the +ResourceConfig file. Filename is +relative to the ServerRoot. +This feature can be disabled using: +

AccessConfig /dev/null
+Historically, this file only contained +<Directory> sections; in fact it can now +contain any server directive allowed in the server config context. +


+ +

AccessFileName directive

+ +Syntax: AccessFileName filename
+Default: AccessFileName .htaccess
+Context: server config, virtual host
+Status: core

+ +When returning a document to the client the server looks for an +access control file with this name in every directory of the path to +the document, if access control files are enabled for that directory. + +For example: +

AccessFileName .acl
+before returning the document /usr/local/web/index.html, the +server will read /.acl, /usr/.acl, /usr/local/.acl and /usr/local/web/.acl +for directives, unless they have been disabled with +
+<Directory />
+AllowOverride None
+</Directory>


+ +

AllowOverride directive

+ +Syntax: AllowOverride override override ...
+Default: AllowOverride All
+Context: directory
+Status: core

+ +When the server finds an .htaccess file (as specified by +AccessFileName) it needs to know which +directives declared in that file can override earlier access information.

+ +Override can be set to None, in which case the server +will not read the file, All in which case the server will +allow all the directives, or one or more of the following: +

+
AuthConfig +
+ +Allow use of the authorization directives +(AuthDBMGroupFile, +AuthDBMUserFile, +AuthGroupFile, +AuthName, AuthType, +AuthUserFile and +require). +
FileInfo +
+ +Allow use of the directives controlling document types +(AddEncoding, +AddLanguage, +AddType, +DefaultType and +LanguagePriority). +
Indexes +
+ +Allow use of the directives controlling directory indexing +(AddDescription, +AddIcon, +AddIconByEncoding, +AddIconByType, +DefaultIcon, +DirectoryIndex, +FancyIndexing, +HeaderName, +IndexIgnore, +IndexOptions and +ReadmeName). +
Limit +
+ +Allow use of the directives controlling host access (allow, deny and order). +
Options +
+ +Allow use of the directives controlling specific directory features +(Options and +XBitHack). +


+ +

AuthName directive

+ +Syntax: AuthName auth-domain
+Context: directory, .htaccess
+Override: AuthConfig
+Status: core

+ +This directive sets the name of the authorization realm for a directory. +This realm is given to the client so that the user knows which username and +password to send. +It must be accompanied by AuthType and +require directives, and directives such as +AuthUserFile and +AuthGroupFile to work.


+ +

AuthType directive

+ +Syntax: AuthType type
+Context: directory, .htaccess
+Override: AuthConfig
+Status: core

+ +This directive selects the type of user authentication for a directory. +Only Basic is currently implemented. + +It must be accompanied by AuthName and +require directives, and directives such as +AuthUserFile and +AuthGroupFile to work.


+ + +

BindAddress directive

+ +Syntax: BindAddress saddr
+Default: BindAddress *
+Context: server config
+Status: core

+ +A Unix® http server can either listen on for connections to every +IP address of the server machine, or just one IP address of the server +machine. Saddr can be + +

+
  • * +
  • An IP address +
  • A fully-qualified internet domain name +
  • +If the value is *, then the server will listen for connections on +every IP address, otherwise it will only listen on the IP address +specified.

    + +This option can be used as an alternative method for supporting +virtual hosts instead of using +<VirtualHost> sections.


    + +

    See Also: +Setting which addresses and ports Apache uses

    + +

    DefaultType directive

    + +Syntax: DefaultType mime-type
    +Default: DefaultType text/html
    +Context: server config, virtual host, directory, .htaccess
    +Override: FileInfo
    +Status: core

    + +There will be times when the server is asked to provide a document +whose type cannot be determined by its MIME types mappings.

    + +The server must inform the client of the content-type of the document, so in +the event of an unknown type it uses the DefaultType. For +example: +

    DefaultType image/gif
    +would be appropriate for a directory which contained many gif images +with filenames missing the .gif extension.


    + +

    <Directory> directive

    + +Syntax: <Directory directory> ... +</Directory>
    +Context: server config, virtual host
    +Status: Core.

    + +<Directory> and </Directory> are used to enclose a group of +directives which will apply only to the named directory and sub-directories +of that directory. Any directive which is allowed in a directory +context may be used. Directory is either the full path to a directory, +or a wildcard string. In a wildcard string, `?' matches any single character, +and `*' matches any sequences of characters. Example: +

    + +<Directory /usr/local/httpd/htdocs>
    +Options Indexes FollowSymLinks
    +</Directory>
    +If multiple directory sections match the directory (or its parents) containing +a document, then the directives are applied in the order of shortest match +first, interspersed with the directives from the +.htaccess files. For example, with +
    +<Directory />
    +AllowOverride None
    +</Directoy>

    +<Directory /home/*>
    +AllowOverride FileInfo
    +</Directory>
    +The for access to the document /home/web/dir/doc.html the +steps are: + +
  • Apply directive AllowOverride None (disabling +.htaccess files). +
  • Apply directive AllowOverride FileInfo (for directory +/home/web). +
  • Apply any FileInfo directives in /home/web/.htaccess +
  • + +The directory sections typically occur in the access.conf file, but they +may appear in any configuration file. <Directory> directives cannot +nest, and cannot appear in a <Limit> section. +


    + +

    DocumentRoot directive

    + +Syntax: DocumentRoot directory-filename
    +Default: DocumentRoot +/usr/local/etc/httpd/htdocs
    +Context: server config, virtual host
    +Status: core

    + +This directive sets the directory from which httpd will serve files. +Unless matched by a directive like Alias, the server appends the path +from the requested URL to the document root to make the path to the +document. Example: +

    DocumentRoot /usr/web
    +then an access to http://www.my.host.com/index.html refers +to /usr/web/index.html. + +

    There appears to be a bug in mod_dir which causes problems when the +DocumentRoot has a trailing slash (i.e. "DocumentRoot /usr/web/") so +please avoid that. + +


    + +

    ErrorDocument directive

    + +Syntax: ErrorDocument error-code document
    +Context server config, virtual host, directory, .htaccess
    +Status: core
    +Compatibility: The directory and .htaccess contexts +are only available in Apache 1.1 and later.

    + +In the event of a problem or error, Apache can be configured to do +one of four things, + +

      +
    1. behave like NCSA httpd 1.3 +
    2. output a customized message +
    3. redirect to a local URL to handle the problem/error +
    4. redirect to an external URL to handle the problem/error +
    + +

    2-4 are configured using ErrorDocument, which +is followed by the HTTP response code and a message or URL. + +

    Messages in this context, begin with a single quote +("), which does not form part of the message itself. Apache will +sometime offer additional information regarding the problem/error. This can be +embedded into the message using %s + +

    URLs will begin with a slash (/) for local URLs, or will be a full +URL which the client can resolve. Examples: +

    +ErrorDocument 500 /cgi-bin/tester
    +ErrorDocument 404 /cgi-bin/bad_urls.pl
    +ErrorDocument 401 http://www2.foo.bar/subscription_info.html
    +ErrorDocument 403 "Sorry can't allow you access today +
    + +See Also: documentation of customizable +responses.


    + +

    ErrorLog directive

    + +Syntax: ErrorLog filename
    +Default: ErrorLog logs/error_log
    +Context: server config, virtual host
    +Status: core

    + +The error log directive sets the name of the file to which the server will log +any errors it encounters. If the filename does not begin with a slash (/) +then it is assumed to be relative to the ServerRoot. +Example: +

    ErrorLog /dev/null
    +This effectively turns off error logging.


    + +

    Group directive

    + +Syntax: Group unix-group
    +Default: Group #-1
    +Context: server config
    +Status: core

    + +The Group directive sets the group under which the server will answer requests. +In order to use this directive, the standalone server must be run initially +as root. Unix-group is one of: +

    +
    A group name +
    Refers to the given group by name. +
    # followed by a group number. +
    Refers to a group by its number. +
    + +It is recommended that you set up a new group specifically for running the +server. Some admins use user nobody, but this is not always +possible or desirable.

    + +Note: if you start the server as a non-root user, it will fail to change +to the specified, and will instead continue to run as the group of the +original user.

    + +SECURITY: See User for a discussion of the security +considerations.


    + +

    IdentityCheck directive

    + +Syntax: IdentityCheck boolean
    +Default: IdentityCheck off
    +Context: server config, virtual host, directory, .htaccess
    +Status: core

    + +This directive enables RFC931-compliant logging of the remote user name +for each connection, where the client machine runs identd or something similar. +This information is logged in the access log. Boolean is either +on or off.

    + +The information should not trusted in any way except for rudimentary usage +tracking.


    + +

    KeepAlive

    +Syntax: KeepAlive max-requests
    +Default: KeepAlive 5
    +Context: server config
    +Status: Core
    +Compatibility: KeepAlive is only available in Apache +1.1 and later.

    + +This directive enables +Keep-Alive +support. Set max-requests +to the maximum number of requests you want Apache to entertain per +request. A limit is imposed to prevent a client from hogging your +server resources. Set this to 0 to disable support. + +

    KeepAliveTimeout

    +Syntax: KeepAliveTimeout seconds
    +Default: KeepAliveTimeout 15
    +Context: server config
    +Status: Core
    +Compatibility: KeepAliveTimeout is only available in Apache +1.1 and later.

    + +The number of seconds Apache will wait for a subsequent request before +closing the connection. Once a request has been received, the timeout +value specified by the Timeout directive +applies. + + +

    Listen

    +Syntax: +Listen [IP address:]port number
    +Context: server config
    +Status: core
    +Compatibility: Listen is only available in Apache +1.1 and later.

    + +

    The Listen directive instructs Apache to listen to more than one IP +address or port; by default it responds to requests on all IP +interfaces, but only on the port given by the Port +directive.

    + +

    See Also: +Setting which addresses and ports Apache uses

    + +

    <Limit> directive

    + +Syntax: + <Limit method method ... > ... </Limit>
    +Context: any
    +Status: core

    + +<Limit> and </Limit> are used to enclose a group of +access control directives which will then apply only to the specified +access methods, where method is any valid HTTP method. +Any directive except another <Limit> or +<Directory> may be used; the majority will be +unaffected by the <Limit>. Example: +

    +<Limit GET POST>
    +require valid-user
    +</Limit>
    +If an access control directive appears outside a <Limit> directive, +then it applies to all access methods.


    + +

    <Location>

    + +Syntax: <Location URL prefix>
    +Context: server config, virtual host
    +Status: core
    +Compatibility: Location is only available in Apache +1.1 and later.

    + +

    The <Location> directive provides for access control by +URL. It is comprable to the <Directory> directive, and +should be matched with a </Location> directive. Directives that +apply to the URL given should be listen +within. <Location> sections are processed in the +order they appear in the configuration file, after the +<Directory> sections and .htaccess files are +read.

    + +

    Note that, due to the way HTTP functions, URL prefix +should, save for proxy requests, be of the form /path/, +and should not include the http://servername. It doesn't +neccessarily have to protect a directory (it can be an individual +file, or a number of files), and can include wildcards. In a wildcard +string, `?' matches any single character, and `*' matches any +sequences of characters. + +

    This functionality is especially useful when combined with the +SetHandler +directive. For example, to enable status requests, but allow them only +from browsers at foo.com, you might use: + +

    +    <Location /status>
    +    SetHandler server-status
    +    
    +    order deny,allow
    +    deny from all
    +    allow from .foo.com
    +    
    +    </Location>
    +
    + + +

    MaxClients directive

    + +Syntax: MaxClients number
    +Default: MaxClients 150
    +Context: server config
    +Status: core

    + +The MaxClients directive sets the limit on the number of simultaneous +requests that can be supported; not more than this number of child server +processes will be created.


    + +

    MaxRequestsPerChild directive

    + +Syntax: MaxRequestsPerChild number
    +Default: MaxRequestsPerChild 0
    +Context: server config
    +Status: core

    + +The MaxRequestsPerChild directive sets the limit on the number of requests +that an individual child server process will handle. After MaxRequestsPerChild +requests, the child process will die. If MaxRequestsPerChild is 0, then +the process will never expire.

    + +Setting MaxRequestsPerChild to a non-zero limit has two beneficial effects: +


    + +

    MaxSpareServers directive

    + +Syntax: MaxSpareServers number
    +Default: MaxSpareServers 10
    +Context: server config
    +Status: core

    + +The MaxSpareServers directive sets the desired maximum number of idle +child server processes. An idle process is one which is not handling +a request. If there are more than MaxSpareServers idle, then the parent +process will kill off the excess processes.

    + +Tuning of this parameter should only be necessary on very busy sites. +Setting this parameter to a large number is almost always a bad idea.

    + +See also MinSpareServers and +StartServers.


    + +

    MinSpareServers directive

    + +Syntax: MinSpareServers number
    +Default: MinSpareServers 5
    +Context: server config
    +Status: core

    + +The MinSpareServers directive sets the desired minimum number of idle +child server processes. An idle process is one which is not handling +a request. If there are fewer than MinSpareServers idle, then the parent +process creates new children at a maximum rate of 1 per second.

    + +Tuning of this parameter should only be necessary on very busy sites. +Setting this parameter to a large number is almost always a bad idea.

    + +See also MaxSpareServers and +StartServers.


    + +

    Options directive

    + +Syntax: Options option option ...
    +Context: server config, virtual host, directory, .htaccess
    +Override: Options
    +Status: core

    + +The Options directive controls which server features are available in +a particular directory.

    +option can be set to None, in which case none of +the extra features are enabled, or one or more of the following: +

    +
    All +
    All options except for MultiViews. +
    ExecCGI +
    + +Execution of CGI scripts is permitted. +
    FollowSymLinks +
    + +The server will follow symbolic links in this directory. +
    Includes +
    + +Server-side includes are permitted. +
    IncludesNOEXEC +
    + +Server-side includes are permitted, but the #exec command and +#include of CGI scripts are disabled. +
    Indexes +
    + +If a URL which maps to a directory is requested, and the there is no +DirectoryIndex (e.g. index.html) in that directory, then the server will +return a formatted listing of the directory. +
    MultiViews +
    + +Ccontent negotiatad MultiViews are +allowed. +
    SymLinksIfOwnerMatch +
    + +The server will only follow symbolic links for which the target +file or directory is owned by the same user id as the link. +
    + +If multiple Options could apply to a directory, then the most specific one is +taken complete; the options are not merged. For example: +
    +<Directory /web/docs>
    +Options Indexes FollowSymLinks
    +</Directory>
    +<Directory /web/docs/spec>
    +Options Includes
    +</Directory> +
    +then only Includes will be set for the /web/docs/spec +directory.


    + +

    PidFile directive

    + +Syntax: PidFile filename
    +Default: PidFile logs/httpd.pid
    +Context: server config
    +Status: core

    + +The PidFile directive sets the file to which the server records the +process id of the daemon. If the filename does not begin with a slash (/) +then it is assumed to be relative to the ServerRoot. +The PidFile is only used in standalone mode.

    + +It is often useful to be able to send the server a signal, so that it closes +and then reopens its ErrorLog and TransferLog, and +re-reads its configuration files. This is done by sending a SIGHUP (kill -1) +signal to the process id listed in the PidFile.


    + +

    Port directive

    + +Syntax: Port number
    +Default: Port 80
    +Context: server config
    +Status: core

    + +The Port directive sets the network port on which the server listens. +Num is a number from 0 to 65535; some port numbers (especially below +1024) are reserved for particular protocols. See /etc/services +for a list of some defined ports; the standard port for the http protocol +is 80.

    + +Port 80 is one of Unix's special ports. All ports numbered +below 1024 are reserved for system use, i.e. regular (non-root) users cannot +make use of them; instead they can only use higher port numbers.

    + +To use port 80, you must start the server from the root account. +After binding to the port and before accepting requests, Apache will change +to a low privileged user as set by the User directive.

    + +If you cannot use port 80, choose any other unused port. Non-root users +will have to choose a port number higher than 1023, such as 8000.

    + +SECURITY: if you do start the server as root, be sure +not to set User to root. If you run the server as +root whilst handling connections, your site may be open to a major security +attack.


    + +

    require directive

    + +Syntax: require entity-name entity entity...
    +Context: directory, .htaccess
    +Override: AuthConfig
    +Status: core

    + +This directive selects which authenticated users can access a directory. +The allowed syntaxes are: +

    +

    +If require appears in a <Limit> +section, then it restricts access to the named methods, otherwise +it restricts access for all methods. Example: +

    +AuthType Basic
    +AuthName somedomain
    +AuthUserFile /web/users
    +AuthGroupFile /web/groups
    +Limit <GET POST>
    +require group admin
    +</Limit> +
    + +Require must be accompanied by AuthName and +AuthType directives, and directives such as +AuthUserFile and +AuthGroupFile (to define users and +groups) in order to work correctly.


    + +

    ResourceConfig directive

    + +Syntax: ResourceConfig filename
    +Default: ResourceConfig conf/srm.conf
    +Context: server config, virtual host
    +Status: core

    + +The server will read this file for more directives after reading the +httpd.conf file. Filename is relative to the +ServerRoot. +This feature can be disabled using: +

    ResourceConfig /dev/null
    +Historically, this file contained most directives except for server +configuration directives and <Directory>. +sections; in fact it can now contain any server directive allowed in the +server config context.

    + +See also AccessConfig.


    + +

    ServerAdmin directive

    + +Syntax: ServerAdmin email-address
    +Context: server config, virtual host
    +Status: core

    + +The ServerAdmin sets the e-mail address that the server includes in any +error messages it returns to the client.

    + +It may be worth setting up a dedicated address for this, e.g. +

    ServerAdmin www-admin@foo.bar.com
    +as users do not always mention that they are talking about the server!


    + +

    ServerAlias directive

    + +Syntax: ServerAlias host1 host2 ...
    +Context: virtual host
    +Status: core
    +Compatibility: ServerAlias is only available in Apache +1.1 and later.

    + +The ServerAlias directive sets the alternate names for a host, for use +with +Host-header based virtual hosts. + +


    + +

    ServerName directive

    + +Syntax: ServerName fully-qualified domain name
    +Context: server config, virtual host
    +Status: core

    + +The ServerName directive sets the hostname of the server; this is only +used when creating redirection URLs. If it is not specified, then the +server attempts to deduce it from its own IP address; however this may +not work reliably, or may not return the preferred hostname. For example: +

    ServerName www.wibble.com
    +would be used if the canonical (main) name of the actual machine +were monster.wibble.com.


    + +

    ServerPath directive

    + +Syntax: ServerPath pathname
    +Context: virtual host
    +Status: core
    +Compatibility: ServerPath is only available in Apache +1.1 and later.

    + +The ServerAlias directive sets the legacy URL pathname for a host, for +use with Host-header based virtual hosts. + +

    ServerRoot directive

    + +Syntax: ServerRoot directory-filename
    +Default: ServerRoot /usr/local/etc/httpd
    +Context: server config
    +Status: core

    + +The ServerRoot directive sets the directory in which the server lives. +Typically it will contain the subdirectories conf/ and +logs/. Relative paths for other configuration files are taken +as relative to this directory.


    + +

    ServerType directive

    + +Syntax: ServerType type
    +Default: ServerType standalone
    +Context: server config
    +Status: core

    + +The ServerType directive sets how the server is executed by the system. +Type is one of +

    +
    inetd +
    The server will be run from the system process inetd; the command to start +the server is added to /etc/inetd.conf +
    standalone +
    The server will run as a daemon process; the command to start the server +is added to the system startup scripts. (/etc/rc.local or +/etc/rc3.d/....) +
    + +Inetd is the lesser used of the two options. For each http +connection received, a new copy of the server is started from scratch; +after the connection is complete, this program exits. There is a high price to +pay per connection, but for security reasons, some admins prefer this option. +

    + +Standalone is the most common setting for ServerType since +it is far more efficient. The server is started once, and services all +subsequent connections. If you intend running Apache to serve a busy site, +standalone will probably be your only option.

    + +SECURITY: if you are paranoid about security, run in inetd mode. Security +cannot be guaranteed in either, but whilst most people are happy to use +standalone, inetd is probably least prone to attack.


    + +

    StartServers directive

    + +Syntax: StartServers number
    +Default: StartServers 5
    +Context: server config
    +Status: core

    + +The StartServers directive sets the number of child server processes created +on startup. As the number of processes is dynamically controlled depending +on the load, there is usually little reason to adjust this parameter.

    + +See also MinSpareServers and +MaxSpareServers.


    + +

    TimeOut directive

    + +Syntax: TimeOut number
    +Default: TimeOut 1200
    +Context: server config
    +Status: core

    + +The TimeOut directive sets the maximum time that the server will wait +for the receipt of a request and the completion of a request, in seconds. +So if it takes more than TimeOut seconds for a client to send a request or +receive a response, the server will break off the connection. Thus TimeOut +limits the maximum a transfer can take; for large files, and slow networks +transfer times can be large. +


    + +

    User directive

    + +Syntax: User unix-userid
    +Default: User #-1
    +Context: server config
    +Status: core

    + +The User directive sets the userid as which the server will answer requests. +In order to use this directive, the standalone server must be run initially +as root. Unix-userid is one of: +

    +
    A username +
    Refers to the given user by name. +
    # followed by a user number. +
    Refers to a user by their number. +
    + +The user should have no privileges which result in it being able to access +files which are not intended to be visible to the outside world, and +similarly, the user should not be able to execute code which is not +meant for httpd requests. It is recommended that you set up a new user and +group specifically for running the server. Some admins use user +nobody, but this is not always possible or desirable.

    + +Notes: If you start the server as a non-root user, it will fail to change +to the lesser privileged user, and will instead continue to run as +that original user. If you do start the server as root, then it is normal +for the parent process to remain running as root.

    + +SECURITY: Don't set User (or Group) to +root unless you know exactly what you are doing, and what the +dangers are.


    + +

    <VirtualHost> directive

    + +Syntax: <VirtualHost addr[:port]> ... +</VirtualHost>
    +Context: server config
    +Status: Core.

    + +<VirtualHost> and </VirtualHost> are used to enclose a group of +directives which will apply only to a particular virtual host. +Any directive which is allowed in a virtual host context may be used. +When the server receives a request for a document on a particular virtual +host, it uses the configuration directives enclosed in the <VirtualHost> +section. Addr can be +

    +
  • The IP address of the virtual host +
  • A fully qualified domain name for the IP address of the virtual host. +
  • Example: +
    + +<VirtualHost host.foo.com>
    +ServerAdmin webmaster@host.foo.com
    +DocumentRoot /www/docs/host.foo.com
    +ServerName host.foo.com
    +ErrorLog logs/host.foo.com-error_log
    +TransferLog logs/host.foo.com-access_log
    +</VirtualHost> +
    + +Currently, each VirtualHost must correspond to a different IP address for +the server, so the server machine must be configured to accept IP packets for +multiple addresses. If the machine does not have multiple network interfaces, +then this can be accomplished with the ifconfig alias command +(if your OS supports it), or with kernel patches like +VIF (for SunOS(TM) 4.1.x).

    + + +

    See also: +Information on Virtual Hosts. +(multihome)
    +See also: +Non-IP address-based Virtual Hosts +

    + +
    + + +Home +Index + + + + diff --git a/docs/manual/mod/index.html b/docs/manual/mod/index.html new file mode 100644 index 0000000000..6a4fcfd1a5 --- /dev/null +++ b/docs/manual/mod/index.html @@ -0,0 +1,78 @@ + + + +Apache modules + + + + +

    Apache modules

    + +
    +
    Core +
    Core Apache features. +
    mod_access +
    Host based access control. +
    mod_actions Apache 1.1 and later. +
    Filetype/method-based script execution +
    mod_alias +
    Aliase and redirects. +
    mod_asis +
    The .asis file handler. +
    mod_auth +
    User authentication using text files. +
    mod_auth_anon +
    Anonymous user authentication, FTP-style. +
    mod_auth_db +
    User authentication using Berkeley DB files. +
    mod_auth_dbm +
    User authentication using DBM files. +
    mod_auth_msql +
    User authentication using mSQL files. +
    mod_cern_meta +
    Support for HTTP header metafiles. +
    mod_cgi +
    Invoking CGI scripts. +
    mod_cookies +
    Support for Netscape-like cookies. +
    mod_digest +
    MD5 authentication +
    mod_dir +
    Automatic directory listings. +
    mod_env +
    Passing of environments to CGI scripts +
    mod_dld +
    Start-time linking with the GNU libdld. +
    mod_imap +
    The imagemap file handler. +
    mod_include +
    Server-parsed documents. +
    mod_info +
    Server configuration information +
    mod_log_agent +
    Logging of User Agents. +
    mod_log_common +
    Standard logging in the Common Logfile Format. +
    mod_log_config +
    User-configurable logging replacement for mod_log_common. +
    mod_log_referer +
    Logging of document references. +
    mod_mime +
    Determining document types. +
    mod_negotiation +
    Content negotation. +
    mod_proxy +
    Caching proxy abilities +
    mod_status +
    Server status display +
    mod_userdir +
    User home directories. +
    + +
    + +Home +Index + + + -- 2.40.0