From: Daniel Earl Poirier Date: Thu, 19 Aug 2010 18:05:20 +0000 (+0000) Subject: Update transforms and add some html and meta files generated from new pages X-Git-Tag: 2.3.8~21 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=8f2f7c1807153d748eaf71031512d41401df1734;p=thirdparty%2Fapache%2Fhttpd.git Update transforms and add some html and meta files generated from new pages git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@987255 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/developer/new_api_2_4.html b/docs/manual/developer/new_api_2_4.html new file mode 100644 index 00000000000..f13974a3bca --- /dev/null +++ b/docs/manual/developer/new_api_2_4.html @@ -0,0 +1,5 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: new_api_2_4.html.en +Content-Language: en +Content-type: text/html; charset=ISO-8859-1 diff --git a/docs/manual/developer/new_api_2_4.html.en b/docs/manual/developer/new_api_2_4.html.en new file mode 100644 index 00000000000..778078630f7 --- /dev/null +++ b/docs/manual/developer/new_api_2_4.html.en @@ -0,0 +1,241 @@ + + + +API Changes in Apache HTTP Server 2.4 since 2.2 - Apache HTTP Server + + + + +
+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.3

+
+
<-
+
+Apache > HTTP Server > Documentation > Version 2.3

API Changes in Apache HTTP Server 2.4 since 2.2

+
+

Available Languages:  en 

+
+ +

This document describes changes to the Apache HTTPD API from + version 2.2 to 2.4, that may be of interest to module/application + developers and core hacks. At the time of writing, the 2.4 API + is not finalised, and this document may serve to highlight + points that call for further review.

+

API changes fall into two categories: APIs that are altogether new, + and existing APIs that are expanded or changed. The latter are + further divided into those where all changes are back-compatible + (so existing modules can ignore them), and those that might + require attention by maintainers. As with the transition from + HTTPD 2.0 to 2.2, existing modules and applications will require + recompiling and may call for some attention, but most should not + require any substantial updating (although some may be able to + take advantage of API changes to offer significant improvements).

+

For the purpose of this document, the API is split according + to the public header files. These headers are themselves the + reference documentation, and can be used to generate a browsable + HTML reference with make docs.

+
+ +
top
+
+

ap_expr (NEW!)

+ +

Introduces a new API to parse and evaluate boolean and algebraic + expressions, including provision for a standard syntax and + customised variants.

+
top
+
+

ap_listen (changed; back-compatible)

+ +

Introduces new API to enable apache child processes to serve different purposes.

+
top
+
+

ap_mpm (changed)

+ +

ap_mpm_run is replaced by a new mpm hook. + Also ap_graceful_stop_signalled is lost, and + ap_mpm_register_timed_callback is new.

+
top
+
+

ap_slotmem (NEW!)

+ +

Introduces an API for modules to allocate and manage memory slots + (normally) for shared memory.

+
top
+
+

ap_socache (NEW!)

+ +

API to manage a shared object cache.

+
top
+
+

heartbeat (NEW!)

+ +

common structures for heartbeat modules (should this be public API?)

+
top
+
+

http_config (changed)

+ +
    +
  • Introduces per-module, per-directory loglevels, including macro wrappers.
    • +
  • New AP_DECLARE_MODULE macro to declare all modules.
    • +
  • New APLOG_USE_MODULE macro necessary for per-module loglevels in + multi-file modules.
    • +
  • New API to retain data across module unload/load
    • +
  • New check_config hook
    • +
  • New ap_process_fnmatch_configs() to process wildcards
    • +
+
top
+
+

http_core (changed)

+ +
    +
  • REMOVED ap_default_type, ap_requires, all 2.2 authnz API
    • +
  • Introduces Optional Functions for logio and authnz
    • +
  • New function ap_get_server_name_for_url to support ipv6 literals.
    • +
+
top
+
+

httpd (changed)

+ +
    +
  • Introduce per-directory, per-module loglevel
    • +
  • New loglevels APLOG_TRACEn
    • +
  • Support for mod_request kept_body
    • +
  • Support buffering filter data for async requests
    • +
  • New CONN_STATE values
    • +
  • Function changes: ap_escape_html updated; ap_unescape_all, ap_escape_path_segment_buffer
    • +
+
top
+
+

http_log (changed)

+ +
    +
  • Introduce per-directory, per-module loglevel
    • +
  • New loglevels APLOG_TRACEn
    • +
  • ap_log_*error become macro wrappers (fully back-compatible if + APLOG_MARK macro is used)
    • +
  • piped logging revamped
    • +
  • module_index added to error_log hook
    • +
  • new function: ap_log_command_line
    • +
+
top
+
+

http_request (changed)

+ +
    +
  • New auth_internal API and auth_provider API
    • +
  • New EOR bucket type
    • +
  • New function ap_process_async_request
    • +
  • New flags AP_AUTH_INTERNAL_PER_CONF and AP_AUTH_INTERNAL_PER_URI
    • +
  • New access_checker_ex hook to apply additional access control and/or + bypass authentication.
    • +
  • New functions ap_hook_check_access_ex, ap_hook_check_access, + ap_hook_check_authn, ap_hook_check_authz which accept + AP_AUTH_INTERNAL_PER_* flags
    • +
  • DEPRECATED direct use of ap_hook_access_checker, access_checker_ex, + ap_hook_check_user_id, ap_hook_auth_checker
    • +
+

When possible, registering all access control hooks (including + authentication and authorization hooks) using AP_AUTH_INTERNAL_PER_CONF + is recommended. If all modules' access control hooks are registered + with this flag, then whenever the server handles an internal + sub-request that matches the same set of access control configuration + directives as the initial request (which is the common case), it can + avoid invoking the access control hooks another time.

+

If your module requires the old behavior and must perform access + control checks on every sub-request with a different URI from the + initial request, even if that URI matches the same set of access + control configuration directives, then use AP_AUTH_INTERNAL_PER_URI.

+
top
+
+

mod_auth (NEW!)

+ +

Introduces the new provider framework for authn and authz

+
top
+
+

mod_core (NEW!)

+ +

This introduces low-level APIs to send arbitrary headers, + and exposes functions to handle HTTP OPTIONS and TRACE.

+
top
+
+

mod_request (NEW!)

+ +

The API for mod_request, to make input data + available to multiple application/handler modules where required, + and to parse HTML form data.

+
top
+
+

mpm_common (changed)

+ +
    +
  • REMOVES: accept, lockfile, lock_mech, set_scoreboard (locking uses the new ap_mutex API)
    • +
  • NEW API to drop privileges (delegates this platform-dependent + function to modules)
    • +
  • NEW Hooks: mpm_query, mpm_note_child_killed, timed_callback, get_name, and function ap_mpm_note_child_killed
    • +
+
top
+
+

scoreboard (changed)

+ +

ap_get_scoreboard_worker is gratuitously made non-back-compatible + as an alternative version is introduced. Additional proxy_balancer + support. Child status stuff revamped.

+
top
+
+

util_cookies (NEW!)

+ +

Introduces a new API for managing HTTP Cookies.

+
top
+
+

util_ldap (changed)

+ +

I have yet to get a handle on this update.

+
top
+
+

util_mutex (NEW!)

+ +

A wrapper for APR proc and global mutexes in httpd.

+
top
+
+

util_script (changed)

+ +

NEW: ap_args_to_table

+
top
+
+

util_time (changed)

+ +

NEW: ap_recent_ctime_ex

+
+
+

Available Languages:  en 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/core.html.en b/docs/manual/mod/core.html.en index 0beb7c5438d..d8706e03db2 100644 --- a/docs/manual/mod/core.html.en +++ b/docs/manual/mod/core.html.en @@ -2645,6 +2645,10 @@ are necessary.

+

If no matching virtual host is found, then the first listed + virtual host that matches the IP address and port will be used.

+ +

IPv6 addresses must be enclosed in square brackets, as shown in the following example:

@@ -3128,6 +3132,11 @@ itself ServerName www.example.com:80

+

The ServerName directive + may appear anywhere within the definition of a server. However, + each appearance overrides the previous appearance (within that + server).

+

If no ServerName is specified, then the server attempts to deduce the hostname by performing a reverse lookup on the IP address. If no port is specified in the @@ -3732,6 +3741,11 @@ hostname or IP address ServerName from the "main" server configuration will be inherited.

+

If no matching virtual host is found, then the first listed + virtual host that matches the IP address will be used. As a + consequence, the first listed virtual host is the default virtual + host.

+

Security

See the security tips document for details on why your security could be compromised if the diff --git a/docs/manual/mod/core.xml.de b/docs/manual/mod/core.xml.de index 51a51136152..d954d550748 100644 --- a/docs/manual/mod/core.xml.de +++ b/docs/manual/mod/core.xml.de @@ -1,7 +1,7 @@ - + + + +mod_authn_socache - Apache HTTP Server + + + + + +

+

Modules | Directives | FAQ | Glossary | Sitemap

+

Apache HTTP Server Version 2.3

+
+
<-
+ +
+

Apache Module mod_authn_socache

+
+

Available Languages:  en 

+
+ + + + +
Description:Manages a cache of authentication credentials to relieve +the load on backends
Status:Base
Module Identifier:authn_socache_module
Source File:mod_authn_socache.c
Compatibility:Version 2.3 and later
+

Summary

+ +

Maintains a cache of authentication credentials, so that a new backend + lookup is not required for every authenticated request.

+
+ +
top
+
+

Authentication Cacheing

+

Some users of more heavyweight authentication such as SQL database + lookups (mod_authn_dbd) have reported it putting an + unacceptable load on their authentication provider. A typical case + in point is where an HTML page contains hundreds of objects + (images, scripts, stylesheets, media, etc), and a request to the page + generates hundreds of effectively-immediate requests for authenticated + additional contents.

+

mod_authn_socache provides a solution to this problem by + maintaining a cache of authentication credentials.

+
top
+
+

Usage

+

The authentication cache should be used where authentication + lookups impose a significant load on the server, or a backend or + network. Authentication by file (mod_authn_file) + or dbm (mod_authn_dbm) are unlikely to benefit, + as these are fast and lightweight in their own right (though in some + cases, such as a network-mounted file, cacheing may be worthwhile). + Other providers such as SQL or LDAP based authentication are more + likely to benefit, particularly where there is an observed + performance issue. Amongst the standard modules, mod_authnz_ldap manages its own cache, so only + mod_authn_dbd will usually benefit from this cache.

+

The basic rules to cache for a provider are:

+
  1. Include the provider you're cacheing for in an + AuthnCacheProvider directive.
    2. +
  2. List socache ahead of the provider you're + cacheing for in your AuthBasicProvider or AuthDigestProvider directive.
    3. +
+

A simple usage example to accelerate mod_authn_dbd + using dbm as a cache engine:

+ 
+    <Directory /usr/www/myhost/private>
+        AuthType Basic
+        AuthName "Cached Authentication Example"
+        AuthBasicProvider socache dbd
+        AuthDBDUserPWQuery "SELECT password FROM authn WHERE user = %s"
+        AuthnCacheProvider dbd
+        AuthnCacheContext dbd-authn-example
+        AuthnCacheSOCache dbm
+        Require valid-user
+    </Directory>
+
+
top
+
+

Cacheing with custom modules

+

Module developers should note that their modules must be enabled + for cacheing with mod_authn_cache. A single optional API function + ap_authn_cache_store is provided to cache credentials + a provider has just looked up or generated. Usage examples are + available in r957072, in which three authn providers are enabled for cacheing.

+
+
top
+

AuthnCacheContext Directive

+ + + + + + + +
Description:Specify a context string for use in the cache key
Syntax:AuthnCacheContext directory|server|custom-string
Default:directory
Context:directory
Status:Base
Module:mod_authn_socache
+

This directive specifies a string to be used along with the supplied + username (and realm in the case of Digest Authentication) in constructing + a cache key. This serves to disambiguate identical usernames serving + different authentication areas on the server.

+

Two special values for this are directory, which uses + the directory context of the request as a string, and server + which uses the virtual host name.

+

The default is directory, which is also the most + conservative setting. This is likely to be less than optimal, as it + (for example) causes $app-base, $app-base/images, + $app-base/scripts and $app-base/media each to + have its own separate cache key. A better policy is to name the + AuthnCacheContext for the password + provider: for example a htpasswd file or database table.

+

Contexts can be shared across different areas of a server, where + credentials are shared. However, this has potential to become a vector + for cross-site or cross-application security breaches, so this directive + is not permitted in .htaccess contexts.

+ +
+
top
+

AuthnCacheProvider Directive

+ + + + + + + + +
Description:Specify which authn provider(s) to cache for
Syntax:AuthnCacheProvider authn-provider [...]
Default:None
Context:directory, .htaccess
Override:AuthConfig
Status:Base
Module:mod_authn_socache
+

This directive specifies an authentication provider or providers + to cache for. Credentials found by a provider not listed in an + AuthnCacheProvider directive will not be cached.

+ +

For example, to cache credentials found by mod_authn_dbd + or by a custom provider myprovider, but leave those looked + up by lightweight providers like file or dbm lookup alone:

+

+ AuthnCacheProvider dbd myprovider +

+ +
+
top
+

AuthnCacheSOCache Directive

+ + + + + + + +
Description:Select socache backend provider to use
Syntax:AuthnCacheSOCache provider-name
Context:server config
Override:None
Status:Base
Module:mod_authn_socache
+

This is a server-wide setting. If not set, your platform's + default will be used.

+

socache

+

The cache is built on the the socache framework. + We need a link here once that's documented!

+
+ +
+
top
+

AuthnCacheTimeout Directive

+ + + + + + + + +
Description:Set a timeout for cache entries
Syntax:AuthnCacheTimeout timeout (seconds)
Default:300 (5 minutes)
Context:directory, .htaccess
Override:AuthConfig
Status:Base
Module:mod_authn_socache
+

Cacheing authentication data can be a security issue, though short-term + cacheing is unlikely to be a problem. Typically a good solution is to + cache credentials for as long as it takes to relieve the load on a + backend, but no longer, though if changes to your users and passwords + are infrequent then a longer timeout may suit you. The default 300 + seconds (5 minutes) is both cautious and ample to keep the load + on a backend such as dbd (SQL database queries) down.

+

This should not be confused with session timeout, which is an + entirely separate issue. However, you may wish to check your + session-management software for whether cached credentials can + "accidentally" extend a session, and bear it in mind when setting + your timeout.

+ +
+
+
+

Available Languages:  en 

+
+ \ No newline at end of file diff --git a/docs/manual/mod/mod_authn_socache.xml.meta b/docs/manual/mod/mod_authn_socache.xml.meta new file mode 100644 index 00000000000..b8f0d35dc97 --- /dev/null +++ b/docs/manual/mod/mod_authn_socache.xml.meta @@ -0,0 +1,12 @@ + + + + + mod_authn_socache + /mod/ + .. + + + en + + diff --git a/docs/manual/new_api_2_4.html b/docs/manual/new_api_2_4.html new file mode 100644 index 00000000000..f13974a3bca --- /dev/null +++ b/docs/manual/new_api_2_4.html @@ -0,0 +1,5 @@ +# GENERATED FROM XML -- DO NOT EDIT + +URI: new_api_2_4.html.en +Content-Language: en +Content-type: text/html; charset=ISO-8859-1 diff --git a/docs/manual/new_api_2_4.xml.meta b/docs/manual/new_api_2_4.xml.meta new file mode 100644 index 00000000000..fde18204c06 --- /dev/null +++ b/docs/manual/new_api_2_4.xml.meta @@ -0,0 +1,12 @@ + + + + + new_api_2_4 + / + . + + + en + + diff --git a/docs/manual/vhosts/details.html.en b/docs/manual/vhosts/details.html.en index e496b7c8c03..6bdcf8a45d6 100644 --- a/docs/manual/vhosts/details.html.en +++ b/docs/manual/vhosts/details.html.en @@ -29,76 +29,102 @@ exactly what Apache HTTP Server does when deciding what virtual host to serve a request from.

-

If you just want to make it work without - understanding how, here are some - examples.

+

Most users should read about + Name-based vs. IP-based Virtual Hosts to decide which type they + want to use, then read more about name-based + or IP-based virtualhosts, and then see + some examples.

+ +

If you want to understand all the details, then you can + come back to this page.

-

See also

top
-

Configuration File Parsing

+

Configuration File

-

There is a main_server which consists of all the +

There is a main server which consists of all the definitions appearing outside of - <VirtualHost> sections. There are virtual + <VirtualHost> sections.

+ +

There are virtual servers, called vhosts, which are defined by <VirtualHost> sections.

-

The - ServerName directive - may appear anywhere within the definition of a server. However, - each appearance overrides the previous appearance (within that - server).

- -

The main_server has no default - ServerAlias. The default ServerName, - if not specified, is deduced from the server's IP address.

- -

Port numbers specified in the VirtualHost directive do - not influence what port numbers Apache will listen on, they only discriminate between - which VirtualHost will be selected to handle a request.

+

Each VirtualHost directive includes one + or more addresses and optional ports.

+ +

Hostnames can be used in place of IP addresses in a virtual + host definition, but they are resolved at startup and if any name + resolutions fail, those virtual host definitions are ignored. + This is, therefore, not recommended.

+ +

If using IP-based vhosts, the address can be specified + as _default_, which will match a request if no + other vhost has the explicit address on which the request was + received.

+ +

If using name-based vhosts, the address can be specified as + *, which will match a request if no + other vhost has the explicit address on which the request was + received. The corresponding NameVirtualHost + directive must also use *.

+ +

The address appearing in the VirtualHost + directive can have an optional port. If the port is unspecified, + it is treated as a wildcard port, which can also be indicated + explicitly using *. + The wildcard port matches any port.

+ +

(Port numbers specified in the VirtualHost directive do + not influence what port numbers Apache will listen on, they only control + which VirtualHost will be selected to handle a request. + Use the Listen directive to + control the addresses and ports on which the server listens.) +

-

Each address appearing in the VirtualHost - directive can have an optional port. If the port is unspecified - it is treated as a wildcard port. The special port * - indicates a wildcard that matches any port. Collectively the - entire set of addresses (including multiple A - record results from DNS lookups) are called the vhost's +

Collectively the + entire set of addresses (including multiple + results from DNS lookups) are called the vhost's address set.

-

Unless a NameVirtualHost - directive is used for the exact IP address and port pair in the - VirtualHost directive, Apache selects the best match - only on the basis of the IP address (or wildcard) and port number. - If there are multiple identical best matches, the first VirtualHost - appearing in the configuration file will be selected.

- -

If you want Apache to further discriminate on the basis of the - HTTP Host header supplied by the client, the - NameVirtualHost directive must appear - with the exact IP address (or wildcard) and port pair used in a correspnding - set of VirtualHost directives.

- -

The name-based virtual host selection occurs only after the a single IP-based - virtual host has been selected, and only considers the set of virtual hosts - the carry an identical IP address and port pair.

- -

Hostnames can be used in place of IP addresses in a virtual host definition, - but it is resolved at startup and is not recommended.

+

If you want Apache to discriminate on the + basis of the HTTP Host header supplied by the client, + the NameVirtualHost directive must appear + with the exact IP address (or wildcard) and port pair used in a + corresponding set of VirtualHost directives.

+

The + ServerName directive + may appear anywhere within the definition of a server. However, + each appearance overrides the previous appearance (within that + server). If no ServerName is specified, the server + attempts to deduce it from the server's IP address.

-

Multiple NameVirtualHost directives can be used - each with a set of VirtualHost directives but only +

Multiple NameVirtualHost directives can be used, + each with a set of VirtualHost directives, but only one NameVirtualHost directive should be used for each specific IP:port pair.

+

The first name-based vhost in the configuration file for a + given IP:port pair is significant because it is used for all + requests received on that address and port for which no other + vhost for that IP:port pair has a matching ServerName or + ServerAlias. It is also used for all SSL connections if the + server does not support Server Name Indication.

+ +

If there are no vhosts defined for an address in a + NameVirtualHost directive, the + NameVirtualHost directive is ignored at startup and an error is + logged.

+

The ordering of NameVirtualHost and - VirtualHost directives is not important which + VirtualHost directives is not important, which makes the following two examples identical (only the order of the VirtualHost directives for one address set is important, see below):

@@ -152,20 +178,6 @@

(To aid the readability of your configuration you should prefer the left variant.)

-

During initialization a list for each IP address is - generated and inserted into an hash table. If the IP address is - used in a NameVirtualHost directive the list - contains all name-based vhosts for the given IP address. If - there are no vhosts defined for that address the - NameVirtualHost directive is ignored and an error - is logged. For an IP-based vhost the list in the hash table is - empty.

- -

Due to a fast hashing function the overhead of hashing an IP - address during a request is minimal and almost not existent. - Additionally the table is optimized for IP addresses which vary - in the last octet.

-

For every vhost various default values are set. In particular:

@@ -180,31 +192,31 @@ ReceiveBufferSize, or SendBufferSize directive then the respective value is inherited from the - main_server. (That is, inherited from whatever the final - setting of that value is in the main_server.) + main server. (That is, inherited from whatever the final + setting of that value is in the main server.)
  • The "lookup defaults" that define the default directory permissions for a vhost are merged with those of the - main_server. This includes any per-directory configuration + main server. This includes any per-directory configuration information for any module.
  • The per-server configs for each module from the - main_server are merged into the vhost server.
    • + main server are merged into the vhost server. -

    Essentially, the main_server is treated as "defaults" or a +

    Essentially, the main server is treated as "defaults" or a "base" on which to build each vhost. But the positioning of - these main_server definitions in the config file is largely - irrelevant -- the entire config of the main_server has been - parsed when this final merging occurs. So even if a main_server + these main server definitions in the config file is largely + irrelevant -- the entire config of the main server has been + parsed when this final merging occurs. So even if a main server definition appears after a vhost definition it might affect the vhost definition.

    -

    If the main_server has no ServerName at this +

    If the main server has no ServerName at this point, then the hostname of the machine that httpd - is running on is used instead. We will call the main_server address + is running on is used instead. We will call the main server address set those IP addresses returned by a DNS lookup on the - ServerName of the main_server.

    + ServerName of the main server.

    For any undefined ServerName fields, a name-based vhost defaults to the address given first in the @@ -212,7 +224,7 @@

    Any vhost that includes the magic _default_ wildcard is given the same ServerName as the - main_server.

    + main server.

    top
    @@ -221,72 +233,73 @@

    The server determines which vhost to use for a request as follows:

    -

    Hash table lookup

    +

    IP address lookup

    + +

    When the connection is first received on some address and port, + the server looks for all the VirtualHost definitions + that have the same IP address and port.

    -

    When the connection is first made by a client, the IP - address to which the client connected is looked up in the - internal IP hash table.

    +

    If there are no exact matches for the address and port, then + wildcard (*) matches are considered.

    -

    If the lookup fails (the IP address wasn't found) the - request is served from the _default_ vhost if - there is such a vhost for the port to which the client sent the - request. If there is no matching _default_ vhost - the request is served from the main_server.

    +

    If there are still no matches, then vhosts with IP + address specified as _default_ that match the + port are considered.

    -

    If the IP address is not found in the hash table then the - match against the port number may also result in an entry - corresponding to a NameVirtualHost *, which is - subsequently handled like other name-based vhosts.

    +

    If no matches are found, the request is served by the + main server.

    -

    If the lookup succeeded (a corresponding list for the IP - address was found) the next step is to decide if we have to - deal with an IP-based or a name-base vhost.

    +

    If there are VirtualHost definitions for + the IP address, the next step is to decide if we have to + deal with an IP-based or a name-based vhost.

    IP-based vhost

    -

    If the entry we found has an empty name list then we have - found an IP-based vhost, no further actions are performed and - the request is served from that vhost.

    +

    If there is no NameVirtualHost directive + matching the vhost, no further actions are performed and + the request is served from the first matching vhost.

    Name-based vhost

    -

    If the entry corresponds to a name-based vhost the name list - contains one or more vhost structures. This list contains the - vhosts in the same order as the VirtualHost - directives appear in the config file.

    - -

    The first vhost on this list (the first vhost in the config - file with the specified IP address) has the highest priority - and catches any request to an unknown server name or a request - without a Host: header field.

    - -

    If the client provided a Host: header field the - list is searched for a matching vhost and the first hit on a - ServerName or ServerAlias is taken - and the request is served from that vhost. A Host: - header field can contain a port number, but Apache always +

    If the entry corresponds to a name-based vhost, the "list" in + the remaining steps refers to the list of vhosts that matched, in + the order they were in the configuration file.

    + +

    If the connection is using SSL, the server supports Server Name Indication, and + the SSL client handshake includes the TLS extension with the + requested hostname, then that hostname is used below just like the + Host: header would be used on a non-SSL connection. + Otherwise, the first name-based vhost whose address matched is + used for SSL connections. This is significant because the + vhost determines which certificate the server will use for the + connection.

    + +

    If the request contains a Host: header field, the + list is searched for the first vhost with a matching + ServerName or ServerAlias, and the + request is served from that vhost. A Host: header + field can contain a port number, but Apache always ignores it and matches against the real port to which the client sent the request.

    -

    If the client submitted a HTTP/1.0 request without - Host: header field we don't know to what server - the client tried to connect to. In this case, the first virtual host - (that is, the one listed first in the server configuration file) for - the IP address and port to which the client connected, is - used to serve this request.

    +

    The first vhost in the config + file with the specified IP address has the highest priority + and catches any request to an unknown server name, or a request + without a Host: header field (such as a HTTP/1.0 + request).

    Persistent connections

    -

    The IP lookup described above is only done once for a - particular TCP/IP session while the name lookup is done on +

    The IP lookup described above is only done once for a + particular TCP/IP session while the name lookup is done on every request during a KeepAlive/persistent - connection. In other words a client may request pages from + connection. In other words, a client may request pages from different name-based vhosts during a single persistent connection.

    @@ -326,7 +339,7 @@ configuration file has the highest priority for its corresponding address set. -
  • The Host: header field is never used during the +
  • Any port in the Host: header field is never used during the matching process. Apache always uses the real port to which the client sent the request.
    • @@ -348,15 +361,15 @@ extension of the "best match" principle, as a specific and exact match is favored over a wildcard. -
  • The main_server is only used to serve a request if the IP - address and port number to which the client connected is - unspecified and does not match any other vhost (including a - _default_ vhost). In other words the main_server +
  • The main server is only used to serve a request if the IP + address and port number to which the client connected + does not match any vhost (including a + _default_ vhost). In other words, the main server only catches a request for an unspecified address/port combination (unless there is a _default_ vhost which matches that port).
    • -
  • A _default_ vhost or the main_server is +
  • A _default_ vhost or the main server is never matched for a request with an unknown or missing Host: header field if the client connected to an address (and port) which is used for @@ -385,7 +398,7 @@ some further tips:

      -
    • Place all main_server definitions before any +
    • Place all main server definitions before any VirtualHost definitions. (This is to aid the readability of the configuration -- the post-config merging process makes it non-obvious that definitions mixed in around diff --git a/docs/manual/vhosts/details.xml.fr b/docs/manual/vhosts/details.xml.fr index e020c9e5a44..a4e883aea09 100644 --- a/docs/manual/vhosts/details.xml.fr +++ b/docs/manual/vhosts/details.xml.fr @@ -1,7 +1,7 @@ - + diff --git a/docs/manual/vhosts/details.xml.ko b/docs/manual/vhosts/details.xml.ko index bd36ff4bbe2..52905b029f1 100644 --- a/docs/manual/vhosts/details.xml.ko +++ b/docs/manual/vhosts/details.xml.ko @@ -1,7 +1,7 @@ - + + + + + + + + diff --git a/docs/manual/vhosts/name-based.xml.ja b/docs/manual/vhosts/name-based.xml.ja index 16d2ebb55f5..55f0128a821 100644 --- a/docs/manual/vhosts/name-based.xml.ja +++ b/docs/manual/vhosts/name-based.xml.ja @@ -1,7 +1,7 @@ - + + +