From: Ken Coar Date: Wed, 15 Apr 2015 20:16:24 +0000 (+0000) Subject: Simply remove trailing whitespace. X-Git-Tag: 2.5.0-alpha~3275 X-Git-Url: https://granicus.if.org/sourcecode?a=commitdiff_plain;h=0566cf0f319e883e584ec02dc95697bce3e38624;p=apache Simply remove trailing whitespace. git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@1673947 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/bind.xml b/docs/manual/bind.xml index 888ef9387e..33bfd2d1a9 100644 --- a/docs/manual/bind.xml +++ b/docs/manual/bind.xml @@ -105,7 +105,7 @@ Listen 192.0.2.5:8000 (48)Address already in use: make_sock: could not bind to address [::]:80 -

See See the discussion in the wiki for further troubleshooting tips.

@@ -205,4 +205,3 @@ Listen 192.0.2.1:80 server is not listening to, it cannot be accessed.

- diff --git a/docs/manual/caching.html.en b/docs/manual/caching.html.en index aa01809c58..b2b5978040 100644 --- a/docs/manual/caching.html.en +++ b/docs/manual/caching.html.en @@ -41,7 +41,7 @@

Introduction

- +

The Apache HTTP server offers a range of caching features that are designed to improve the performance of the server in various ways.

@@ -100,7 +100,7 @@
Related ModulesRelated Directives

The HTTP protocol contains built in support for an in-line caching - mechanism + mechanism described by section 13 of RFC2616, and the mod_cache module can be used to take advantage of @@ -175,14 +175,14 @@

In this scenario, the cache behaves as if it has been "bolted on" to the front of the server.

- +

This mode offers the best performance, as the majority of server processing is bypassed. This mode however also bypasses the authentication and authorization phases of server processing, so this mode should be chosen with care when this is important.

- +

Requests with an "Authorization" header (for example, HTTP Basic - Authentication) are neither cacheable nor served from the cache + Authentication) are neither cacheable nor served from the cache when mod_cache is running in this phase.

Normal handler phase
@@ -237,7 +237,7 @@ explicit freshness lifetime with the Cache-Control header's max-age or s-maxage fields, or by including an Expires header.

- +

At the same time, the origin server defined freshness lifetime can be overridden by a client when the client presents their own Cache-Control header within the request. In this case, @@ -302,7 +302,7 @@ see if the file has changed in size or modification time. As such, even local content may still be served faster from the cache if it has not changed.

- +

Origin servers should make every effort to support conditional requests as is practical, however if conditional requests are not supported, the origin will respond as if the request was not @@ -375,7 +375,7 @@ particulars of the request that are not covered by HTTP negotiation, should not be cached. This content should declare itself uncacheable using the Cache-Control header.

- +

If content changes often, expressed by a freshness lifetime of minutes or seconds, the content can still be cached, however it is highly desirable that the origin server supports @@ -395,7 +395,7 @@ based on the value of headers in the request, for example to serve multiple languages at the same URL, HTTP's caching mechanism makes it possible to cache multiple variants of the same page at the same URL.

- +

This is done by the origin server adding a Vary header to indicate which headers must be taken into account by a cache when determining whether two variants are different from one another.

@@ -409,7 +409,7 @@ Vary: negotiate,accept-language,accept-charset

mod_cache will only serve the cached content to requesters with accept-language and accept-charset headers matching those of the original request.

- +

Multiple variants of the content can be cached side by side, mod_cache uses the Vary header and the corresponding values of the request headers listed by Vary @@ -514,7 +514,7 @@ CacheDirLength 1 or more to process very large (tens of gigabytes) caches and if you are running it from cron it is recommended that you determine how long a typical run takes, to avoid running more than one instance at a time.

- +

It is also recommended that an appropriate "nice" level is chosen for htcacheclean so that the tool does not cause excessive disk io while the server is running.

@@ -537,7 +537,7 @@ CacheDirLength 1
Related ModulesRelated Directives
- +

The Apache HTTP server offers a low level shared object cache for caching information such as SSL sessions, or authentication credentials, within the socache interface.

@@ -816,7 +816,7 @@ sys 0m0.000s
on the popularity of the particular web site thousands or millions of duplicate cache entries could be created for the same URL, crowding out other entries in the cache.

- +

In other cases, there may be a need to change the URL of a particular resource on every request, usually by adding a "cachebuster" string to the URL. If this content is declared cacheable by a server for a diff --git a/docs/manual/caching.xml b/docs/manual/caching.xml index f08ed7a77f..9a7112e5d5 100644 --- a/docs/manual/caching.xml +++ b/docs/manual/caching.xml @@ -34,7 +34,7 @@

Introduction - +

The Apache HTTP server offers a range of caching features that are designed to improve the performance of the server in various ways.

@@ -104,7 +104,7 @@

The HTTP protocol contains built in support for an in-line caching - mechanism + mechanism described by section 13 of RFC2616, and the mod_cache module can be used to take advantage of @@ -180,14 +180,14 @@

In this scenario, the cache behaves as if it has been "bolted on" to the front of the server.

- +

This mode offers the best performance, as the majority of server processing is bypassed. This mode however also bypasses the authentication and authorization phases of server processing, so this mode should be chosen with care when this is important.

- +

Requests with an "Authorization" header (for example, HTTP Basic - Authentication) are neither cacheable nor served from the cache + Authentication) are neither cacheable nor served from the cache when mod_cache is running in this phase.

Normal handler phase
@@ -242,7 +242,7 @@ explicit freshness lifetime with the Cache-Control header's max-age or s-maxage fields, or by including an Expires header.

- +

At the same time, the origin server defined freshness lifetime can be overridden by a client when the client presents their own Cache-Control header within the request. In this case, @@ -309,7 +309,7 @@ see if the file has changed in size or modification time. As such, even local content may still be served faster from the cache if it has not changed.

- +

Origin servers should make every effort to support conditional requests as is practical, however if conditional requests are not supported, the origin will respond as if the request was not @@ -384,7 +384,7 @@ particulars of the request that are not covered by HTTP negotiation, should not be cached. This content should declare itself uncacheable using the Cache-Control header.

- +

If content changes often, expressed by a freshness lifetime of minutes or seconds, the content can still be cached, however it is highly desirable that the origin server supports @@ -404,7 +404,7 @@ based on the value of headers in the request, for example to serve multiple languages at the same URL, HTTP's caching mechanism makes it possible to cache multiple variants of the same page at the same URL.

- +

This is done by the origin server adding a Vary header to indicate which headers must be taken into account by a cache when determining whether two variants are different from one another.

@@ -418,7 +418,7 @@ Vary: negotiate,accept-language,accept-charset

mod_cache will only serve the cached content to requesters with accept-language and accept-charset headers matching those of the original request.

- +

Multiple variants of the content can be cached side by side, mod_cache uses the Vary header and the corresponding values of the request headers listed by Vary @@ -527,7 +527,7 @@ CacheDirLength 1 or more to process very large (tens of gigabytes) caches and if you are running it from cron it is recommended that you determine how long a typical run takes, to avoid running more than one instance at a time.

- +

It is also recommended that an appropriate "nice" level is chosen for htcacheclean so that the tool does not cause excessive disk io while the server is running.

@@ -565,7 +565,7 @@ CacheDirLength 1 SSLStaplingCache - +

The Apache HTTP server offers a low level shared object cache for caching information such as SSL sessions, or authentication credentials, within the socache interface.

@@ -872,7 +872,7 @@ sys 0m0.000s on the popularity of the particular web site thousands or millions of duplicate cache entries could be created for the same URL, crowding out other entries in the cache.

- +

In other cases, there may be a need to change the URL of a particular resource on every request, usually by adding a "cachebuster" string to the URL. If this content is declared cacheable by a server for a diff --git a/docs/manual/compliance.html.en b/docs/manual/compliance.html.en index 63f804b930..b15cc6892a 100644 --- a/docs/manual/compliance.html.en +++ b/docs/manual/compliance.html.en @@ -179,12 +179,12 @@

This policy will be rejected if the server response does not contain an explicit Content-Length header.

- +

There are a number of ways of determining the length of a response body, described in full in RFC2616 section 4.4 Message Length.

- +

When the Content-Length header is present, the size of the body is declared at the start of the response. If this information is missing, an HTTP cache might choose to ignore the response, as it @@ -231,9 +231,9 @@ header, and the format of the header is described in full in RFC2616 section 3.7 Media Types.

- +

A syntactically valid content type might look as follows:

- +

Content-Type: text/html; charset=iso-8859-1

@@ -244,7 +244,7 @@ # invalid
Content-Type: foo
# blank
- Content-Type: + Content-Type:

The server administrator has the option to restrict the policy to one @@ -263,12 +263,12 @@

This policy will be rejected if the server response does not contain an explicit Content-Length header, or a Transfer-Encoding of chunked.

- +

There are a number of ways of determining the length of a response body, described in full in RFC2616 section 4.4 Message Length.

- +

When the Content-Length header is present, the size of the body is declared at the start of the response. HTTP/1.1 defines the Transfer-Encoding header as an alternative to @@ -281,33 +281,33 @@

Most specifically, we follow these rules:

- +
IF
we have not marked this connection as errored;
- +
and
the client isn't expecting 100-continue
- +
and
the response status does not require a close;
- +
and
the response body has a defined length due to the status code being 304 or 204, the request method being HEAD, already having defined Content-Length or Transfer-Encoding: chunked, or the request version being HTTP/1.1 and thus capable of being set as chunked
- +
THEN
we support keepalive.
- +
The server may choose to turn off keepalive for various reasons, such as an imminent shutdown, or a Connection: close from the client, or an HTTP/1.0 client request with a response with no Content-Length, but for our purposes we only care that keepalive was possible from the application, not that keepalive actually - took place.
+ took place.

It should also be noted that the Apache httpd server includes a filter that adds chunked encoding to responses without an explicit content @@ -316,7 +316,7 @@

This policy is implemented by the POLICY_KEEPALIVE filter.

- +
top

Freshness Lifetime / Maxage Policy

@@ -418,7 +418,7 @@

Vary Header Policy

Related ModulesRelated Directives
- +

This policy will be rejected if the server response contains a Vary header, and that header in turn contains a header blacklisted by the administrator.

@@ -426,7 +426,7 @@

The Vary header is described in full in RFC2616 section 14.44 Vary.

- +

Some client provided headers, such as User-Agent, can contain thousands or millions of combinations of values over a period of time, and if the response is declared cacheable, a cache might attempt diff --git a/docs/manual/compliance.xml b/docs/manual/compliance.xml index 1449353520..ddef10098a 100644 --- a/docs/manual/compliance.xml +++ b/docs/manual/compliance.xml @@ -199,12 +199,12 @@

This policy will be rejected if the server response does not contain an explicit Content-Length header.

- +

There are a number of ways of determining the length of a response body, described in full in RFC2616 section 4.4 Message Length.

- +

When the Content-Length header is present, the size of the body is declared at the start of the response. If this information is missing, an HTTP cache might choose to ignore the response, as it @@ -258,9 +258,9 @@ header, and the format of the header is described in full in RFC2616 section 3.7 Media Types.

- +

A syntactically valid content type might look as follows:

- + Content-Type: text/html; charset=iso-8859-1 @@ -271,7 +271,7 @@ # invalid
Content-Type: foo
# blank
- Content-Type: + Content-Type:

The server administrator has the option to restrict the policy to one @@ -297,12 +297,12 @@

This policy will be rejected if the server response does not contain an explicit Content-Length header, or a Transfer-Encoding of chunked.

- +

There are a number of ways of determining the length of a response body, described in full in RFC2616 section 4.4 Message Length.

- +

When the Content-Length header is present, the size of the body is declared at the start of the response. HTTP/1.1 defines the Transfer-Encoding header as an alternative to @@ -315,33 +315,33 @@

Most specifically, we follow these rules:

- +
IF
we have not marked this connection as errored;
- +
and
the client isn't expecting 100-continue
- +
and
the response status does not require a close;
- +
and
the response body has a defined length due to the status code being 304 or 204, the request method being HEAD, already having defined Content-Length or Transfer-Encoding: chunked, or the request version being HTTP/1.1 and thus capable of being set as chunked
- +
THEN
we support keepalive.
- + The server may choose to turn off keepalive for various reasons, such as an imminent shutdown, or a Connection: close from the client, or an HTTP/1.0 client request with a response with no Content-Length, but for our purposes we only care that keepalive was possible from the application, not that keepalive actually - took place. + took place.

It should also be noted that the Apache httpd server includes a filter that adds chunked encoding to responses without an explicit content @@ -350,7 +350,7 @@

This policy is implemented by the POLICY_KEEPALIVE filter.

- +
@@ -392,7 +392,7 @@ filter.

- +
No Cache Policy @@ -434,7 +434,7 @@ filter.

- +
Validation Policy @@ -469,7 +469,7 @@ filter.

- +
Vary Header Policy @@ -480,7 +480,7 @@ PolicyVary - +

This policy will be rejected if the server response contains a Vary header, and that header in turn contains a header blacklisted by the administrator.

@@ -488,7 +488,7 @@

The Vary header is described in full in RFC2616 section 14.44 Vary.

- +

Some client provided headers, such as User-Agent, can contain thousands or millions of combinations of values over a period of time, and if the response is declared cacheable, a cache might attempt @@ -500,7 +500,7 @@ filter.

- +
Protocol Version Policy diff --git a/docs/manual/configuring.html.en b/docs/manual/configuring.html.en index af05c9243d..e1cb57fe95 100644 --- a/docs/manual/configuring.html.en +++ b/docs/manual/configuring.html.en @@ -69,14 +69,14 @@ Server.

There must be no other characters or white space between the backslash and the end of the line.

-

Arguments to directives are separated by whitespace. If an +

Arguments to directives are separated by whitespace. If an argument contains spaces, you must enclose that argument in quotes.

Directives in the configuration files are case-insensitive, but arguments to directives are often case sensitive. Lines that begin with the hash character "#" are considered comments, and are ignored. Comments may not be - included on the same line as a configuration directive. + included on the same line as a configuration directive. White space occurring before a directive is ignored, so you may indent directives for clarity. Blank lines are also ignored.

diff --git a/docs/manual/configuring.xml b/docs/manual/configuring.xml index c301a6b00a..672491b2a8 100644 --- a/docs/manual/configuring.xml +++ b/docs/manual/configuring.xml @@ -69,14 +69,14 @@ Server.

There must be no other characters or white space between the backslash and the end of the line.

-

Arguments to directives are separated by whitespace. If an +

Arguments to directives are separated by whitespace. If an argument contains spaces, you must enclose that argument in quotes.

Directives in the configuration files are case-insensitive, but arguments to directives are often case sensitive. Lines that begin with the hash character "#" are considered comments, and are ignored. Comments may not be - included on the same line as a configuration directive. + included on the same line as a configuration directive. White space occurring before a directive is ignored, so you may indent directives for clarity. Blank lines are also ignored.

diff --git a/docs/manual/developer/hooks.html.en b/docs/manual/developer/hooks.html.en index 2381e188e3..808b016254 100644 --- a/docs/manual/developer/hooks.html.en +++ b/docs/manual/developer/hooks.html.en @@ -29,9 +29,9 @@ date.

-

In general, a hook function is one that the Apache HTTP Server - will call at some point during the processing of a request. - Modules can provide functions that are called, and specify when +

In general, a hook function is one that the Apache HTTP Server + will call at some point during the processing of a request. + Modules can provide functions that are called, and specify when they get called in comparison to other modules.

  • Creating a hook function
    • @@ -103,7 +103,7 @@

    The first hook that does not return DECLINED stops the loop and its return value is returned from the hook - caller. Note that DECLINED is the traditional + caller. Note that DECLINED is the traditional hook return value meaning "I didn't do anything", but it can be whatever suits you.

    @@ -181,7 +181,7 @@ mode MODULE_VAR_EXPORT my_module = order relative to each other, but, of course, all modules using APR_HOOK_FIRST will be run before APR_HOOK_MIDDLE which are before APR_HOOK_LAST. Modules that don't care - when they are run should use APR_HOOK_MIDDLE. These + when they are run should use APR_HOOK_MIDDLE. These values are spaced out, so that positions like APR_HOOK_FIRST-2 are possible to hook slightly earlier than other functions.

    diff --git a/docs/manual/developer/hooks.xml b/docs/manual/developer/hooks.xml index e9a5c5f52e..fcd4ce07eb 100644 --- a/docs/manual/developer/hooks.xml +++ b/docs/manual/developer/hooks.xml @@ -31,9 +31,9 @@ date.

    -

    In general, a hook function is one that the Apache HTTP Server - will call at some point during the processing of a request. - Modules can provide functions that are called, and specify when +

    In general, a hook function is one that the Apache HTTP Server + will call at some point during the processing of a request. + Modules can provide functions that are called, and specify when they get called in comparison to other modules.

    @@ -106,7 +106,7 @@ void ap_run_do_something(request_rec *r, int n)

    The first hook that does not return DECLINED stops the loop and its return value is returned from the hook - caller. Note that DECLINED is the traditional + caller. Note that DECLINED is the traditional hook return value meaning "I didn't do anything", but it can be whatever suits you.

    @@ -188,7 +188,7 @@ mode MODULE_VAR_EXPORT my_module = order relative to each other, but, of course, all modules using APR_HOOK_FIRST will be run before APR_HOOK_MIDDLE which are before APR_HOOK_LAST. Modules that don't care - when they are run should use APR_HOOK_MIDDLE. These + when they are run should use APR_HOOK_MIDDLE. These values are spaced out, so that positions like APR_HOOK_FIRST-2 are possible to hook slightly earlier than other functions.

    @@ -220,4 +220,3 @@ static void register_hooks()
- diff --git a/docs/manual/developer/modguide.html.en b/docs/manual/developer/modguide.html.en index 593e79fef5..d1af3203c9 100644 --- a/docs/manual/developer/modguide.html.en +++ b/docs/manual/developer/modguide.html.en @@ -24,7 +24,7 @@

Available Languages:  en 

-

This document explains how you can develop modules for the Apache HTTP +

This document explains how you can develop modules for the Apache HTTP Server 2.4

  • Introduction
    • @@ -41,46 +41,46 @@ Server 2.4

    Introduction

    What we will be discussing in this document

    -This document will discuss how you can create modules for the Apache -HTTP Server 2.4, by exploring an example module called -mod_example. In the first part of this document, the purpose -of this module will be to calculate and print out various digest values for +This document will discuss how you can create modules for the Apache +HTTP Server 2.4, by exploring an example module called +mod_example. In the first part of this document, the purpose +of this module will be to calculate and print out various digest values for existing files on your web server, whenever we access the URL -http://hostname/filename.sum. For instance, if we want to know the +http://hostname/filename.sum. For instance, if we want to know the MD5 digest value of the file located at http://www.example.com/index.html, we would visit -http://www.example.com/index.html.sum. +http://www.example.com/index.html.sum.

    -In the second part of this document, which deals with configuration -directive and context awareness, we will be looking at a module that simply +In the second part of this document, which deals with configuration +directive and context awareness, we will be looking at a module that simply writes out its own configuration to the client.

    Prerequisites

    -First and foremost, you are expected to have a basic knowledge of how the C -programming language works. In most cases, we will try to be as pedagogical -as possible and link to documents describing the functions used in the -examples, but there are also many cases where it is necessary to either -just assume that "it works" or do some digging yourself into what the hows -and whys of various function calls. +First and foremost, you are expected to have a basic knowledge of how the C +programming language works. In most cases, we will try to be as pedagogical +as possible and link to documents describing the functions used in the +examples, but there are also many cases where it is necessary to either +just assume that "it works" or do some digging yourself into what the hows +and whys of various function calls.

    -Lastly, you will need to have a basic understanding of how modules are -loaded and configured in the Apache HTTP Server, as well as how to get the headers for -Apache if you do not have them already, as these are needed for compiling +Lastly, you will need to have a basic understanding of how modules are +loaded and configured in the Apache HTTP Server, as well as how to get the headers for +Apache if you do not have them already, as these are needed for compiling new modules.

    Compiling your module

    -To compile the source code we are building in this document, we will be -using APXS. Assuming your source file -is called mod_example.c, compiling, installing and activating the module is -as simple as: +To compile the source code we are building in this document, we will be +using APXS. Assuming your source file +is called mod_example.c, compiling, installing and activating the module is +as simple as: 

    apxs -i -a -c mod_example.c
    @@ -90,13 +90,13 @@ as simple as:

    Defining a module

    Module name tags
    -Every module starts with the same declaration, or name tag if you will, +Every module starts with the same declaration, or name tag if you will, that defines a module as a separate entity within Apache:

    module AP_MODULE_DECLARE_DATA   example_module =
-{ 
+{
     STANDARD20_MODULE_STUFF,
     create_dir_conf, /* Per-directory configuration handler */
     merge_dir_conf,  /* Merge handler for per-directory configurations */
@@ -109,8 +109,8 @@ that defines a module as a separate entity within Apache:
    
 
 
 
    
-This bit of code lets the server know that we have now registered a new module 
-in the system, and that its name is example_module. The name 
+This bit of code lets the server know that we have now registered a new module
+in the system, and that its name is example_module. The name
 of the module is used primarily for two things:
    
 
    
 
      
@@ -118,20 +118,20 @@ of the module is used primarily for two things:
      
 
    • Setting up a namespace for the module to use in configurations
      • 
 
    
 
    
-For now, we're only concerned with the first purpose of the module name, 
+For now, we're only concerned with the first purpose of the module name,
 which comes into play when we need to load the module:
 
    
 
    LoadModule example_module "modules/mod_example.so"
    
 
 
    
-In essence, this tells the server to open up mod_example.so and look for a module 
+In essence, this tells the server to open up mod_example.so and look for a module
 called example_module.
 
    
 
    
-Within this name tag of ours is also a bunch of references to how we would 
-like to handle things: Which directives do we respond to in a configuration 
-file or .htaccess, how do we operate within specific contexts, and what 
-handlers are we interested in registering with the Apache HTTP service. We'll 
+Within this name tag of ours is also a bunch of references to how we would
+like to handle things: Which directives do we respond to in a configuration
+file or .htaccess, how do we operate within specific contexts, and what
+handlers are we interested in registering with the Apache HTTP service. We'll
 return to all these elements later in this document.
top
@@ -139,50 +139,50 @@ return to all these elements later in this document.

Getting started: Hooking into the server

An introduction to hooks

-When handling requests in Apache HTTP Server 2.4, the first thing you will need to do is -create a hook into the request handling process. A hook is essentially a -message telling the server that you are willing to either serve or at least -take a glance at certain requests given by clients. All handlers, whether -it's mod_rewrite, mod_authn_*, mod_proxy and so on, are hooked into -specific parts of the request process. As you are probably aware, modules -serve different purposes; Some are authentication/authorization handlers, -others are file or script handlers while some third modules rewrite URIs or -proxies content. Furthermore, in the end, it is up to the user of the server -how and when each module will come into place. Thus, the server itself does not -presume to know which module is responsible for handling a specific -request, and will ask each module whether they have an interest in a given -request or not. It is then up to each module to either gently decline -serving a request, accept serving it or flat out deny the request from +When handling requests in Apache HTTP Server 2.4, the first thing you will need to do is +create a hook into the request handling process. A hook is essentially a +message telling the server that you are willing to either serve or at least +take a glance at certain requests given by clients. All handlers, whether +it's mod_rewrite, mod_authn_*, mod_proxy and so on, are hooked into +specific parts of the request process. As you are probably aware, modules +serve different purposes; Some are authentication/authorization handlers, +others are file or script handlers while some third modules rewrite URIs or +proxies content. Furthermore, in the end, it is up to the user of the server +how and when each module will come into place. Thus, the server itself does not +presume to know which module is responsible for handling a specific +request, and will ask each module whether they have an interest in a given +request or not. It is then up to each module to either gently decline +serving a request, accept serving it or flat out deny the request from being served, as authentication/authorization modules do:
Hook handling in httpd
-To make it a bit easier for handlers such as our mod_example to know -whether the client is requesting content we should handle or not, the server -has directives for hinting to modules whether their assistance is needed or -not. Two of these are AddHandler -and SetHandler. Let's take a look at -an example using AddHandler. In -our example case, we want every request ending with .sum to be served by -mod_example, so we'll add a configuration directive that tells +To make it a bit easier for handlers such as our mod_example to know +whether the client is requesting content we should handle or not, the server +has directives for hinting to modules whether their assistance is needed or +not. Two of these are AddHandler +and SetHandler. Let's take a look at +an example using AddHandler. In +our example case, we want every request ending with .sum to be served by +mod_example, so we'll add a configuration directive that tells the server to do just that: 

AddHandler example-handler ".sum"

-What this tells the server is the following: Whenever we receive a request -for a URI ending in .sum, we are to let all modules know that we are -looking for whoever goes by the name of "example-handler" . -Thus, when a request is being served that ends in .sum, the server will let all +What this tells the server is the following: Whenever we receive a request +for a URI ending in .sum, we are to let all modules know that we are +looking for whoever goes by the name of "example-handler" . +Thus, when a request is being served that ends in .sum, the server will let all modules know, that this request should be served by "example-handler". -As you will see later, when we start building mod_example, we will -check for this handler tag relayed by AddHandler and reply to +As you will see later, when we start building mod_example, we will +check for this handler tag relayed by AddHandler and reply to the server based on the value of this tag.

Hooking into httpd

-To begin with, we only want to create a simple handler, that replies to the -client browser when a specific URL is requested, so we won't bother setting -up configuration handlers and directives just yet. Our initial module +To begin with, we only want to create a simple handler, that replies to the +client browser when a specific URL is requested, so we won't bother setting +up configuration handlers and directives just yet. Our initial module definition will look like this:

@@ -201,15 +201,15 @@ definition will look like this:

-

This lets the server know that we are not interested in anything fancy, we -just want to hook onto the requests and possibly handle some of them.

+

This lets the server know that we are not interested in anything fancy, we +just want to hook onto the requests and possibly handle some of them.

-

The reference in our example declaration, register_hooks -is the name of a function we will create to manage how we hook onto the -request process. In this example module, the function has just one purpose; -To create a simple hook that gets called after all the rewrites, access -control etc has been handled. Thus, we will let the server know, that we want -to hook into its process as one of the last modules: +

The reference in our example declaration, register_hooks +is the name of a function we will create to manage how we hook onto the +request process. In this example module, the function has just one purpose; +To create a simple hook that gets called after all the rewrites, access +control etc has been handled. Thus, we will let the server know, that we want +to hook into its process as one of the last modules:

@@ -222,13 +222,13 @@ to hook into its process as one of the last modules:

-The example_handler reference is the function that will handle +The example_handler reference is the function that will handle the request. We will discuss how to create a handler in the next chapter.

Other useful hooks

-Hooking into the request handling phase is but one of many hooks that you +Hooking into the request handling phase is but one of many hooks that you can create. Some other ways of hooking are:

    @@ -245,15 +245,15 @@ can create. Some other ways of hooking are:

    Building a handler

    -A handler is essentially a function that receives a callback when a request -to the server is made. It is passed a record of the current request (how it was -made, which headers and requests were passed along, who's giving the -request and so on), and is put in charge of either telling the server that it's +A handler is essentially a function that receives a callback when a request +to the server is made. It is passed a record of the current request (how it was +made, which headers and requests were passed along, who's giving the +request and so on), and is put in charge of either telling the server that it's not interested in the request or handle the request with the tools provided.

    -

    A simple "Hello, world!" -handler

    -

    Let's start off by making a very simple request handler +

    A simple "Hello, world!" +handler

    +

    Let's start off by making a very simple request handler that does the following:

      @@ -274,13 +274,13 @@ In C code, our example handler will now look like this: * and the server will try somewhere else. */ if (!r->handler || strcmp(r->handler, "example-handler")) return (DECLINED); - + /* Now that we are handling this request, we'll write out "Hello, world!" to the client. * To do so, we must first set the appropriate content type, followed by our output. */ ap_set_content_type(r, "text/html"); ap_rprintf(r, "Hello, world!"); - + /* Lastly, we must tell the server that we took care of this request and everything went fine. * We do so by simply returning the value OK to the server. */ @@ -290,19 +290,19 @@ In C code, our example handler will now look like this:

      -Now, we put all we have learned together and end up with a program that -looks like +Now, we put all we have learned together and end up with a program that +looks like mod_example_1.c -. The functions used in this example will be explained later in the section -"Some useful functions you should know". +. The functions used in this example will be explained later in the section +"Some useful functions you should know".

      - -

      The request_rec structure

      + +

      The request_rec structure

      The most essential part of any request is the request record . In a call to a handler function, this is represented by the -request_rec* structure passed along with every call that is made. -This struct, typically just referred to as r in modules, -contains all the information you need for your module to fully process any +request_rec* structure passed along with every call that is made. +This struct, typically just referred to as r in modules, +contains all the information you need for your module to fully process any HTTP request and respond accordingly.

      Some key elements of the request_rec structure are:

      @@ -315,12 +315,12 @@ request_rec structure are:
    1. r->connection (conn_rec*): A record containing information about the current connection
    2. r->user (char*): If the URI requires authentication, this is set to the username provided
    3. r->useragent_ip (char*): The IP address of the client connecting to us
      4. -
    4. r->pool (apr_pool_t*): The memory pool of this request. We'll discuss this in the +
    5. r->pool (apr_pool_t*): The memory pool of this request. We'll discuss this in the "Memory management" chapter.

-A complete list of all the values contained within the request_rec structure can be found in -the httpd.h header +A complete list of all the values contained within the request_rec structure can be found in +the httpd.h header file or at http://ci.apache.org/projects/httpd/trunk/doxygen/structrequest__rec.html.

@@ -337,7 +337,7 @@ Let's try out some of these variables in another example handler:
/* Print out the IP address of the client connecting to us: */ ap_rprintf(r, "<h2>Hello, %s!</h2>", r->useragent_ip); - + /* If we were reached through a GET or a POST request, be happy, else sad. */ if ( !strcmp(r->method, "POST") || !strcmp(r->method, "GET") ) { ap_rputs("You used a GET or a POST method, that makes us happy!<br/>", r); @@ -359,11 +359,11 @@ Let's try out some of these variables in another example handler:

Return values

-Apache relies on return values from handlers to signify whether a request -was handled or not, and if so, whether the request went well or not. If a -module is not interested in handling a specific request, it should always -return the value DECLINED. If it is handling a request, it -should either return the generic value OK, or a specific HTTP +Apache relies on return values from handlers to signify whether a request +was handled or not, and if so, whether the request went well or not. If a +module is not interested in handling a specific request, it should always +return the value DECLINED. If it is handling a request, it +should either return the generic value OK, or a specific HTTP status code, for example:

@@ -377,13 +377,13 @@ status code, for example:

-Returning OK or a HTTP status code does not necessarily mean -that the request will end. The server may still have other handlers that are -interested in this request, for instance the logging modules which, upon a -successful request, will write down a summary of what was requested and how -it went. To do a full stop and prevent any further processing after your -module is done, you can return the value DONE to let the server -know that it should cease all activity on this request and carry on with +Returning OK or a HTTP status code does not necessarily mean +that the request will end. The server may still have other handlers that are +interested in this request, for instance the logging modules which, upon a +successful request, will write down a summary of what was requested and how +it went. To do a full stop and prevent any further processing after your +module is done, you can return the value DONE to let the server +know that it should cease all activity on this request and carry on with the next, without informing other handlers.
General response codes: @@ -413,7 +413,7 @@ the next, without informing other handlers. ap_rputs(const char *string, request_rec *r):
Sends a string of text to the client. This is a shorthand version of ap_rwrite. - + 

ap_rputs("Hello, world!", r);
@@ -425,8 +425,8 @@ the next, without informing other handlers.
  • ap_rprintf:
    - This function works just like printf, except it sends the result to the client. - + This function works just like printf, except it sends the result to the client. + 
    ap_rprintf(r, "Hello, %s!", r->useragent_ip);
    @@ -438,7 +438,7 @@ the next, without informing other handlers. ap_set_content_type(request_rec *r, const char *type):
    Sets the content type of the output you are sending. - + 
    ap_set_content_type(r, "text/plain"); /* force a raw text output */
    @@ -453,18 +453,18 @@ the next, without informing other handlers.

    Memory management

    -Managing your resources in Apache HTTP Server 2.4 is quite easy, thanks to the memory pool -system. In essence, each server, connection and request have their own -memory pool that gets cleaned up when its scope ends, e.g. when a request -is done or when a server process shuts down. All your module needs to do is -latch onto this memory pool, and you won't have to worry about having to +Managing your resources in Apache HTTP Server 2.4 is quite easy, thanks to the memory pool +system. In essence, each server, connection and request have their own +memory pool that gets cleaned up when its scope ends, e.g. when a request +is done or when a server process shuts down. All your module needs to do is +latch onto this memory pool, and you won't have to worry about having to clean up after yourself - pretty neat, huh?

    -In our module, we will primarily be allocating memory for each request, so -it's appropriate to use the r->pool -reference when creating new objects. A few of the functions for allocating +In our module, we will primarily be allocating memory for each request, so +it's appropriate to use the r->pool +reference when creating new objects. A few of the functions for allocating memory within a pool are:

      @@ -487,10 +487,10 @@ apr_pool_t *p, const char *fmt, ...): Similar to sprintf, ex const char *original = "You can't edit this!"; char *copy; int *integers; - + /* Allocate space for 10 integer values and set them all to zero. */ - integers = apr_pcalloc(r->pool, sizeof(int)*10); - + integers = apr_pcalloc(r->pool, sizeof(int)*10); + /* Create a copy of the 'original' variable that we can edit. */ copy = apr_pstrdup(r->pool, original); return OK; @@ -499,10 +499,10 @@ apr_pool_t *p, const char *fmt, ...): Similar to sprintf, ex

      -This is all well and good for our module, which won't need any -pre-initialized variables or structures. However, if we wanted to -initialize something early on, before the requests come rolling in, we -could simply add a call to a function in our register_hooks +This is all well and good for our module, which won't need any +pre-initialized variables or structures. However, if we wanted to +initialize something early on, before the requests come rolling in, we +could simply add a call to a function in our register_hooks function to sort it out:

      @@ -518,36 +518,36 @@ function to sort it out:

      -In this pre-request initialization function we would not be using the -same pool as we did when allocating resources for request-based functions. -Instead, we would use the pool given to us by the server for allocating memory +In this pre-request initialization function we would not be using the +same pool as we did when allocating resources for request-based functions. +Instead, we would use the pool given to us by the server for allocating memory on a per-process based level.

      Parsing request data

      -In our example module, we would like to add a feature, that checks which -type of digest, MD5 or SHA1 the client would like to see. This could be -solved by adding a query string to the request. A query string is typically -comprised of several keys and values put together in a string, for instance -valueA=yes&valueB=no&valueC=maybe. It is up to the -module itself to parse these and get the data it requires. In our example, +In our example module, we would like to add a feature, that checks which +type of digest, MD5 or SHA1 the client would like to see. This could be +solved by adding a query string to the request. A query string is typically +comprised of several keys and values put together in a string, for instance +valueA=yes&valueB=no&valueC=maybe. It is up to the +module itself to parse these and get the data it requires. In our example, we'll be looking for a key called digest, and if set to -md5, we'll produce an MD5 digest, otherwise we'll produce a SHA1 +md5, we'll produce an MD5 digest, otherwise we'll produce a SHA1 digest.

      -Since the introduction of Apache HTTP Server 2.4, parsing request data from GET and -POST requests have never been easier. All we require to parse both GET and +Since the introduction of Apache HTTP Server 2.4, parsing request data from GET and +POST requests have never been easier. All we require to parse both GET and POST data is four simple lines: -

      +

       apr_table_t *GET; 
-apr_array_header_t*POST; 
+apr_array_header_t*POST;
 
 
 
@@ -558,7 +558,7 @@ ap_parse_form_data(r, NULL, &POST, -1, 8192);

      -In our specific example module, we're looking for the digest +In our specific example module, we're looking for the digest value from the query string, which now resides inside a table called GET. To extract this value, we need only perform a simple operation:

      @@ -574,16 +574,16 @@ if (!digestType) digestType = "sha1";

      -The structures used for the POST and GET data are not exactly the same, so -if we were to fetch a value from POST data instead of the query string, we +The structures used for the POST and GET data are not exactly the same, so +if we were to fetch a value from POST data instead of the query string, we would have to resort to a few more lines, as outlined in this example in the last chapter of this document.

      Making an advanced handler

      -Now that we have learned how to parse form data and manage our resources, -we can move on to creating an advanced version of our module, that spits +Now that we have learned how to parse form data and manage our resources, +we can move on to creating an advanced version of our module, that spits out the MD5 or SHA1 digest of files:

      @@ -601,15 +601,15 @@ out the MD5 or SHA1 digest of files: apr_table_t *GET; apr_array_header_t *POST; const char *digestType; - - + + /* Check that the "example-handler" handler is being called. */ if (!r->handler || strcmp(r->handler, "example-handler")) return (DECLINED); - + /* Figure out which file is being requested by removing the .sum from it */ filename = apr_pstrdup(r->pool, r->filename); filename[strlen(filename)-4] = 0; /* Cut off the last 4 characters. */ - + /* Figure out if the file we request a sum on exists and isn't a directory */ rc = apr_stat(&finfo, filename, APR_FINFO_MIN, r->pool); if (rc == APR_SUCCESS) { @@ -622,27 +622,27 @@ out the MD5 or SHA1 digest of files: } /* If apr_stat failed, we're probably not allowed to check this file. */ else return HTTP_FORBIDDEN; - + /* Parse the GET and, optionally, the POST data sent to us */ - + ap_args_to_table(r, &GET); ap_parse_form_data(r, NULL, &POST, -1, 8192); - + /* Set the appropriate content type */ ap_set_content_type(r, "text/html"); - + /* Print a title and some general information */ ap_rprintf(r, "<h2>Information on %s:</h2>", filename); ap_rprintf(r, "<b>Size:</b> %u bytes<br/>", finfo.size); - + /* Get the digest type the client wants to see */ digestType = apr_table_get(GET, "digest"); if (!digestType) digestType = "MD5"; - - + + rc = apr_file_open(&file, filename, APR_READ, APR_OS_DEFAULT, r->pool); if (rc == APR_SUCCESS) { - + /* Are we trying to calculate the MD5 or the SHA1 digest? */ if (!strcasecmp(digestType, "md5")) { /* Calculate the MD5 sum of the file */ @@ -657,7 +657,7 @@ out the MD5 or SHA1 digest of files: apr_md5_update(&md5, buffer, readBytes); } apr_md5_final(digest.chr, &md5); - + /* Print out the MD5 digest */ ap_rputs("<b>MD5: </b><code>", r); for (n = 0; n < APR_MD5_DIGESTSIZE/4; n++) { @@ -680,20 +680,20 @@ out the MD5 or SHA1 digest of files: apr_sha1_update(&sha1, buffer, readBytes); } apr_sha1_final(digest.chr, &sha1); - + /* Print out the SHA1 digest */ ap_rputs("<b>SHA1: </b><code>", r); for (n = 0; n < APR_SHA1_DIGESTSIZE/4; n++) { ap_rprintf(r, "%08x", digest.num[n]); } ap_rputs("</code>", r); - + /* Print a link to the MD5 version */ ap_rputs("<br/><a href='?digest=md5'>View the MD5 hash instead</a>", r); } apr_file_close(file); - - } + + } /* Let the server know that we responded to this request. */ return OK; } @@ -701,7 +701,7 @@ out the MD5 or SHA1 digest of files:

      -This version in its entirety can be found here: +This version in its entirety can be found here: mod_example_2.c.

      @@ -710,19 +710,19 @@ This version in its entirety can be found here:

      Adding configuration options

      -In this next segment of this document, we will turn our eyes away from the -digest module and create a new example module, whose only function is to -write out its own configuration. The purpose of this is to examine how -the server works with configuration, and what happens when you start writing -advanced configurations +In this next segment of this document, we will turn our eyes away from the +digest module and create a new example module, whose only function is to +write out its own configuration. The purpose of this is to examine how +the server works with configuration, and what happens when you start writing +advanced configurations for your modules.

      -

      An introduction to configuration +

      An introduction to configuration directives

      -If you are reading this, then you probably already know -what a configuration directive is. Simply put, a directive is a way of -telling an individual module (or a set of modules) how to behave, such as +If you are reading this, then you probably already know +what a configuration directive is. Simply put, a directive is a way of +telling an individual module (or a set of modules) how to behave, such as these directives control how mod_rewrite works: 

      RewriteEngine On
@@ -730,7 +730,7 @@ RewriteCond "%{REQUEST_URI}"  "^/foo/bar"
 RewriteRule "^/foo/bar/(.*)$" "/foobar?page=$1"

      -Each of these configuration directives are handled by a separate function, +Each of these configuration directives are handled by a separate function, that parses the parameters given and sets up a configuration accordingly.

      @@ -748,9 +748,9 @@ that parses the parameters given and sets up a configuration accordingly.

      -Now, let's put this into perspective by creating a very small module that -just prints out a hard-coded configuration. You'll notice that we use the -register_hooks function for initializing the configuration +Now, let's put this into perspective by creating a very small module that +just prints out a hard-coded configuration. You'll notice that we use the +register_hooks function for initializing the configuration values to their defaults:

      @@ -773,7 +773,7 @@ static int example_handler(request_rec *r) return OK; } -static void register_hooks(apr_pool_t *pool) +static void register_hooks(apr_pool_t *pool) { config.enabled = 1; config.path = "/foo/bar"; @@ -797,7 +797,7 @@ module AP_MODULE_DECLARE_DATA example_module =

      -So far so good. To access our new handler, we could add the following to +So far so good. To access our new handler, we could add the following to our configuration: 

      <Location "/example">
@@ -805,17 +805,17 @@ our configuration:
 </Location>

      -When we visit, we'll see our current configuration being spit out by our -module. +When we visit, we'll see our current configuration being spit out by our +module.

      Registering directives with the server

      -What if we want to change our configuration, not by hard-coding new values -into the module, but by using either the httpd.conf file or possibly a -.htaccess file? It's time to let the server know that we want this to be -possible. To do so, we must first change our name tag to include a +What if we want to change our configuration, not by hard-coding new values +into the module, but by using either the httpd.conf file or possibly a +.htaccess file? It's time to let the server know that we want this to be +possible. To do so, we must first change our name tag to include a reference to the configuration directives we want to register with the server:

      @@ -834,10 +834,10 @@ reference to the configuration directives we want to register with the server:

      -This will tell the server that we are now accepting directives from the +This will tell the server that we are now accepting directives from the configuration files, and that the structure called example_directives - holds information on what our directives are and how they work. -Since we have three different variables in our module configuration, we + holds information on what our directives are and how they work. +Since we have three different variables in our module configuration, we will add a structure with three directives and a NULL at the end:

      @@ -857,34 +857,34 @@ will add a structure with three directives and a NULL at the end: As you can see, each directive needs at least 5 parameters set:

        -
      1. AP_INIT_TAKE1: This is a macro that tells the server that this directive takes one and only one argument. -If we required two arguments, we could use the macro AP_INIT_TAKE2 and so on (refer to httpd_conf.h +
      2. AP_INIT_TAKE1: This is a macro that tells the server that this directive takes one and only one argument. +If we required two arguments, we could use the macro AP_INIT_TAKE2 and so on (refer to httpd_conf.h for more macros).
        3. -
      3. exampleEnabled: This is the name of our directive. More precisely, it is what the user must put in his/her +
      4. exampleEnabled: This is the name of our directive. More precisely, it is what the user must put in his/her configuration in order to invoke a configuration change in our module.
        5. -
      5. example_set_enabled: This is a reference to a C function that parses the directive and sets the configuration +
      6. example_set_enabled: This is a reference to a C function that parses the directive and sets the configuration accordingly. We will discuss how to make this in the following paragraph.
        7. -
      7. RSRC_CONF: This tells the server where the directive is permitted. We'll go into details on this value in the +
      8. RSRC_CONF: This tells the server where the directive is permitted. We'll go into details on this value in the later chapters, but for now, RSRC_CONF means that the server will only accept these directives in a server context.
      9. "Enable or disable....": This is simply a brief description of what the directive does.

      -(The "missing" parameter in our definition, which is usually set to -NULL, is an optional function that can be run after the -initial function to parse the arguments have been run. This is usually -omitted, as the function for verifying arguments might as well be used to +(The "missing" parameter in our definition, which is usually set to +NULL, is an optional function that can be run after the +initial function to parse the arguments have been run. This is usually +omitted, as the function for verifying arguments might as well be used to set them.)

      The directive handler function

      -Now that we have told the server to expect some directives for our module, it's -time to make a few functions for handling these. What the server reads in the -configuration file(s) is text, and so naturally, what it passes along to -our directive handler is one or more strings, that we ourselves need to +Now that we have told the server to expect some directives for our module, it's +time to make a few functions for handling these. What the server reads in the +configuration file(s) is text, and so naturally, what it passes along to +our directive handler is one or more strings, that we ourselves need to recognize and act upon. You'll notice, that since we set our -exampleAction directive to accept two arguments, its C function also -has an additional parameter defined:

      +exampleAction directive to accept two arguments, its C function also +has an additional parameter defined:

      /* Handler for the "exampleEnabled" directive */
@@ -909,7 +909,7 @@ const char *example_set_action(cmd_parms *cmd, void *cfg, const char *arg1, cons
 {
     if(!strcasecmp(arg1, "file")) config.typeOfAction = 0x01;
     else config.typeOfAction = 0x02;
-    
+
     if(!strcasecmp(arg2, "deny")) config.typeOfAction += 0x10;
     else config.typeOfAction += 0x20;
     return NULL;
@@ -921,7 +921,7 @@ const char *example_set_action(cmd_parms *cmd, void *cfg, const char *arg1, cons
 
 
      Putting it all together
      
 
      
-Now that we have our directives set up, and handlers configured for them, 
+Now that we have our directives set up, and handlers configured for them,
 we can assemble our module into one big file:
 
      
 
@@ -978,7 +978,7 @@ const char *example_set_action(cmd_parms *cmd, void *cfg, const char *arg1, cons
 {
     if(!strcasecmp(arg1, "file")) config.typeOfAction = 0x01;
     else config.typeOfAction = 0x02;
-    
+
     if(!strcasecmp(arg2, "deny")) config.typeOfAction += 0x10;
     else config.typeOfAction += 0x20;
     return NULL;
@@ -1016,7 +1016,7 @@ static int example_handler(request_rec *r)
  The hook registration function (also initializes the default config values):
  ==============================================================================
  */
-static void register_hooks(apr_pool_t *pool) 
+static void register_hooks(apr_pool_t *pool)
 {
     config.enabled = 1;
     config.path = "/foo/bar";
@@ -1043,7 +1043,7 @@ module AP_MODULE_DECLARE_DATA   example_module =
 
 
 
      
-In our httpd.conf file, we can now change the hard-coded configuration by 
+In our httpd.conf file, we can now change the hard-coded configuration by
 adding a few lines:
 
      
 
      ExampleEnabled On
@@ -1051,8 +1051,8 @@ ExamplePath "/usr/bin/foo"
 ExampleAction file allow
      
 
 
      
-And thus we apply the configuration, visit /example on our 
-web site, and we see the configuration has adapted to what we wrote in our 
+And thus we apply the configuration, visit /example on our
+web site, and we see the configuration has adapted to what we wrote in our
 configuration file.
 
      
 
@@ -1063,9 +1063,9 @@ configuration file.
 
      Context aware configurations
      
 
      Introduction to context aware configurations
      
 
      
-In Apache HTTP Server 2.4, different URLs, virtual hosts, directories etc can have very 
-different meanings to the user of the server, and thus different contexts 
-within which modules must operate. For example, let's assume you have this 
+In Apache HTTP Server 2.4, different URLs, virtual hosts, directories etc can have very
+different meanings to the user of the server, and thus different contexts
+within which modules must operate. For example, let's assume you have this
 configuration set up for mod_rewrite:
 
      
 
      <Directory "/var/www">
@@ -1077,22 +1077,22 @@ configuration set up for mod_rewrite:
 </Directory>
      
 
 
      
-In this example, you will have set up two different contexts for 
+In this example, you will have set up two different contexts for
 mod_rewrite:
      
 
        
 
      1. Inside /var/www, all requests for http://example.com must go to http://www.example.com
        2. 
 
      2. Inside /var/www/sub, all requests for foobar must go to index.php?foobar=true
        3. 
 
      
 
      
-If mod_rewrite (or the entire server for that matter) wasn't context aware, then 
-these rewrite rules would just apply to every and any request made, 
-regardless of where and how they were made, but since the module can pull 
-the context specific configuration straight from the server, it does not need 
-to know itself, which of the directives are valid in this context, since 
+If mod_rewrite (or the entire server for that matter) wasn't context aware, then
+these rewrite rules would just apply to every and any request made,
+regardless of where and how they were made, but since the module can pull
+the context specific configuration straight from the server, it does not need
+to know itself, which of the directives are valid in this context, since
 the server takes care of this.
      
 
 
      
-So how does a module get the specific configuration for the server, 
+So how does a module get the specific configuration for the server,
 directory or location in question? It does so by making one simple call:
 
      
 
@@ -1102,17 +1102,17 @@ directory or location in question? It does so by making one simple call:
 
 
 
      
-That's it! Of course, a whole lot goes on behind the scenes, which we will 
-discuss in this chapter, starting with how the server came to know what our 
-configuration looks like, and how it came to be set up as it is in the 
+That's it! Of course, a whole lot goes on behind the scenes, which we will
+discuss in this chapter, starting with how the server came to know what our
+configuration looks like, and how it came to be set up as it is in the
 specific context.
 
      
 
 
 
      Our basic configuration setup
      
-
      In this chapter, we will be working with a slightly modified version of 
-our previous context structure. We will set a context 
-variable that we can use to track which context configuration is being 
+
      In this chapter, we will be working with a slightly modified version of
+our previous context structure. We will set a context
+variable that we can use to track which context configuration is being
 used by the server in various places:
 
      
 
@@ -1147,8 +1147,8 @@ used by the server in various places:
 
 
      Choosing a context
      
 
      
-Before we can start making our module context aware, we must first define, 
-which contexts we will accept. As we saw in the previous chapter, defining 
+Before we can start making our module context aware, we must first define,
+which contexts we will accept. As we saw in the previous chapter, defining
 a directive required five elements be set:
      
 
 
@@ -1158,12 +1158,12 @@ a directive required five elements be set:
      
 
 
 
-
      The RSRC_CONF definition told the server that we would only allow 
-this directive in a global server context, but since we are now trying out 
-a context aware version of our module, we should set this to something 
-more lenient, namely the value ACCESS_CONF, which lets us use 
-the directive inside <Directory> and <Location> blocks. For more 
-control over the placement of your directives, you can combine the following 
+
      The RSRC_CONF definition told the server that we would only allow
+this directive in a global server context, but since we are now trying out
+a context aware version of our module, we should set this to something
+more lenient, namely the value ACCESS_CONF, which lets us use
+the directive inside <Directory> and <Location> blocks. For more
+control over the placement of your directives, you can combine the following
 restrictions together to form a specific rule:
 
      
 
        
@@ -1178,11 +1178,11 @@ restrictions together to form a specific rule:
 
 
 
        Using the server to allocate configuration slots
        
-
         A much smarter way to manage your configurations is by letting the server 
-help you create them. To do so, we must first start off by changing our 
-name tag to let the server know, that it should assist us in creating 
-and managing our configurations. Since we have chosen the per-directory 
-(or per-location) context for our module configurations, we'll add a 
+
         A much smarter way to manage your configurations is by letting the server
+help you create them. To do so, we must first start off by changing our
+name tag to let the server know, that it should assist us in creating
+and managing our configurations. Since we have chosen the per-directory
+(or per-location) context for our module configurations, we'll add a
 per-directory creator and merger function reference in our tag:
        
 
 
@@ -1205,9 +1205,9 @@ per-directory creator and merger function reference in our tag:
        
 
 
        Creating new context configurations
        
 
        
-Now that we have told the server to help us create and manage configurations, 
-our first step is to make a function for creating new, blank 
-configurations. We do so by creating the function we just referenced in 
+Now that we have told the server to help us create and manage configurations,
+our first step is to make a function for creating new, blank
+configurations. We do so by creating the function we just referenced in
 our name tag as the Per-directory configuration handler:
        
 
 
        void *create_dir_conf(apr_pool_t *pool, char *context) {
@@ -1230,9 +1230,9 @@ our name tag as the Per-directory configuration handler:
        
 
 
        Merging configurations
        
 
        
-Our next step in creating a context aware configuration is merging 
-configurations. This part of the process particularly applies to scenarios 
-where you have a parent configuration and a child, such as the following: 
+Our next step in creating a context aware configuration is merging
+configurations. This part of the process particularly applies to scenarios
+where you have a parent configuration and a child, such as the following:
 
        
 
        <Directory "/var/www">
     ExampleEnabled On
@@ -1246,8 +1246,8 @@ where you have a parent configuration and a child, such as the following:
 
        
 In this example, it is natural to assume that the directory 
 /var/www/subdir should inherit the values set for the /var/www
- directory, as we did not specify an ExampleEnabled nor 
-an ExamplePath for this directory. The server does not presume to 
+ directory, as we did not specify an ExampleEnabled nor
+an ExamplePath for this directory. The server does not presume to
 know if this is true, but cleverly does the following:
 
        
 
          
@@ -1258,8 +1258,8 @@ know if this is true, but cleverly does the following:
 
        1. Proposes a merge of the two configurations into a new configuration for /var/www/subdir
          2. 
 
        
 
        
-This proposal is handled by the merge_dir_conf function we 
-referenced in our name tag. The purpose of this function is to assess the 
+This proposal is handled by the merge_dir_conf function we
+referenced in our name tag. The purpose of this function is to assess the
 two configurations and decide how they are to be merged:
        
 
 
@@ -1268,12 +1268,12 @@ two configurations and decide how they are to be merged:
        
     example_config *base = (example_config *) BASE ; /* This is what was set in the parent context */
     example_config *add = (example_config *) ADD ;   /* This is what is set in the new context */
     example_config *conf = (example_config *) create_dir_conf(pool, "Merged configuration"); /* This will be the merged configuration */
-    
+
     /* Merge configurations */
     conf->enabled = ( add->enabled == 0 ) ? base->enabled : add->enabled ;
     conf->typeOfAction = add->typeOfAction ? add->typeOfAction : base->typeOfAction;
     strcpy(conf->path, strlen(add->path) ? add->path : base->path);
-    
+
     return conf ;
 }
        
 
@@ -1284,8 +1284,8 @@ two configurations and decide how they are to be merged:
        
 
 
        Trying out our new context aware configurations
        
 
        
-Now, let's try putting it all together to create a new module that is 
-context aware. First off, we'll create a configuration that lets us test 
+Now, let's try putting it all together to create a new module that is
+context aware. First off, we'll create a configuration that lets us test
 how the module works:
 
        
 
        <Location "/a">
@@ -1307,8 +1307,8 @@ how the module works:
 </Location>
        
 
 
        
-Then we'll assemble our module code. Note, that since we are now using our 
-name tag as reference when fetching configurations in our handler, I have 
+Then we'll assemble our module code. Note, that since we are now using our
+name tag as reference when fetching configurations in our handler, I have
 added some prototypes to keep the compiler happy:
 
        
 
@@ -1548,11 +1548,11 @@ void *merge_dir_conf(apr_pool_t *pool, void *BASE, void *ADD)
 
        
 
        Summing up
        
 
        
-We have now looked at how to create simple modules for Apache HTTP Server 2.4 and 
-configuring them. What you do next is entirely up to you, but it is my 
-hope that something valuable has come out of reading this documentation. 
-If you have questions on how to further develop modules, you are welcome 
-to join our mailing lists 
+We have now looked at how to create simple modules for Apache HTTP Server 2.4 and
+configuring them. What you do next is entirely up to you, but it is my
+hope that something valuable has come out of reading this documentation.
+If you have questions on how to further develop modules, you are welcome
+to join our mailing lists
 or check out the rest of our documentation for further tips.
 
        
 
        top
        
@@ -1687,7 +1687,7 @@ static int example_handler(request_rec *r)
     return(rc);
 }
 
-static int example_handler(request_rec *r) 
+static int example_handler(request_rec *r)
 {
     /*~~~~~~~~~~~~~~~~*/
     apr_off_t   size;
diff --git a/docs/manual/developer/modguide.xml b/docs/manual/developer/modguide.xml
index 3857e00c55..50a6b93a27 100644
--- a/docs/manual/developer/modguide.xml
+++ b/docs/manual/developer/modguide.xml
@@ -27,7 +27,7 @@
   Developing modules for the Apache HTTP Server 2.4
 
 
-
        This document explains how you can develop modules for the Apache HTTP 
+
        This document explains how you can develop modules for the Apache HTTP
 Server 2.4
        
         
 
@@ -37,46 +37,46 @@ Server 2.4
        
 
        Introduction
 
        What we will be discussing in this document
 
        
-This document will discuss how you can create modules for the Apache 
-HTTP Server 2.4, by exploring an example module called 
-mod_example. In the first part of this document, the purpose 
-of this module will be to calculate and print out various digest values for 
+This document will discuss how you can create modules for the Apache
+HTTP Server 2.4, by exploring an example module called
+mod_example. In the first part of this document, the purpose
+of this module will be to calculate and print out various digest values for
 existing files on your web server, whenever we access the URL 
-http://hostname/filename.sum. For instance, if we want to know the 
+http://hostname/filename.sum. For instance, if we want to know the
 MD5 digest value of the file located at 
 http://www.example.com/index.html, we would visit 
-http://www.example.com/index.html.sum. 
+http://www.example.com/index.html.sum.
 
        
 
 
        
-In the second part of this document, which deals with configuration 
-directive and context awareness, we will be looking at a module that simply 
+In the second part of this document, which deals with configuration
+directive and context awareness, we will be looking at a module that simply
 writes out its own configuration to the client.
 
        
 
        
 
 
        Prerequisites
 
        
-First and foremost, you are expected to have a basic knowledge of how the C 
-programming language works. In most cases, we will try to be as pedagogical 
-as possible and link to documents describing the functions used in the 
-examples, but there are also many cases where it is necessary to either 
-just assume that "it works" or do some digging yourself into what the hows 
-and whys of various function calls. 
+First and foremost, you are expected to have a basic knowledge of how the C
+programming language works. In most cases, we will try to be as pedagogical
+as possible and link to documents describing the functions used in the
+examples, but there are also many cases where it is necessary to either
+just assume that "it works" or do some digging yourself into what the hows
+and whys of various function calls.
 
        
 
        
-Lastly, you will need to have a basic understanding of how modules are 
-loaded and configured in the Apache HTTP Server, as well as how to get the headers for 
-Apache if you do not have them already, as these are needed for compiling 
+Lastly, you will need to have a basic understanding of how modules are
+loaded and configured in the Apache HTTP Server, as well as how to get the headers for
+Apache if you do not have them already, as these are needed for compiling
 new modules.
 
        
 
        
 
        Compiling your module
 
        
-To compile the source code we are building in this document, we will be 
-using APXS. Assuming your source file 
-is called mod_example.c, compiling, installing and activating the module is 
-as simple as: 
+To compile the source code we are building in this document, we will be
+using APXS. Assuming your source file
+is called mod_example.c, compiling, installing and activating the module is
+as simple as:
 
        
 
         apxs -i -a -c mod_example.c
@@ -88,14 +88,14 @@ apxs -i -a -c mod_example.c
 
        Defining a module
 
        
 Module name tags
        
-Every module starts with the same declaration, or name tag if you will, 
+Every module starts with the same declaration, or name tag if you will,
 that defines a module as a separate entity within Apache:
        
 
 
 
 
 module AP_MODULE_DECLARE_DATA   example_module =
-{ 
+{
     STANDARD20_MODULE_STUFF,
     create_dir_conf, /* Per-directory configuration handler */
     merge_dir_conf,  /* Merge handler for per-directory configurations */
@@ -108,8 +108,8 @@ module AP_MODULE_DECLARE_DATA   example_module =
 
 
 
        
-This bit of code lets the server know that we have now registered a new module 
-in the system, and that its name is example_module. The name 
+This bit of code lets the server know that we have now registered a new module
+in the system, and that its name is example_module. The name
 of the module is used primarily for two things:
        
 
        
 
          
@@ -117,72 +117,72 @@ of the module is used primarily for two things:
          
 
        • Setting up a namespace for the module to use in configurations
          • 
 
        
 
        
-For now, we're only concerned with the first purpose of the module name, 
+For now, we're only concerned with the first purpose of the module name,
 which comes into play when we need to load the module:
 
        
 
 LoadModule example_module "modules/mod_example.so"
 
 
        
-In essence, this tells the server to open up mod_example.so and look for a module 
+In essence, this tells the server to open up mod_example.so and look for a module
 called example_module.
 
        
 
        
-Within this name tag of ours is also a bunch of references to how we would 
-like to handle things: Which directives do we respond to in a configuration 
-file or .htaccess, how do we operate within specific contexts, and what 
-handlers are we interested in registering with the Apache HTTP service. We'll 
+Within this name tag of ours is also a bunch of references to how we would
+like to handle things: Which directives do we respond to in a configuration
+file or .htaccess, how do we operate within specific contexts, and what
+handlers are we interested in registering with the Apache HTTP service. We'll
 return to all these elements later in this document.
 
        
 
        
 
        Getting started: Hooking into the server
 
        An introduction to hooks
 
        
-When handling requests in Apache HTTP Server 2.4, the first thing you will need to do is 
-create a hook into the request handling process. A hook is essentially a 
-message telling the server that you are willing to either serve or at least 
-take a glance at certain requests given by clients. All handlers, whether 
-it's mod_rewrite, mod_authn_*, mod_proxy and so on, are hooked into 
-specific parts of the request process. As you are probably aware, modules 
-serve different purposes; Some are authentication/authorization handlers, 
-others are file or script handlers while some third modules rewrite URIs or 
-proxies content. Furthermore, in the end, it is up to the user of the server 
-how and when each module will come into place. Thus, the server itself does not 
-presume to know which module is responsible for handling a specific 
-request, and will ask each module whether they have an interest in a given 
-request or not. It is then up to each module to either gently decline 
-serving a request, accept serving it or flat out deny the request from 
+When handling requests in Apache HTTP Server 2.4, the first thing you will need to do is
+create a hook into the request handling process. A hook is essentially a
+message telling the server that you are willing to either serve or at least
+take a glance at certain requests given by clients. All handlers, whether
+it's mod_rewrite, mod_authn_*, mod_proxy and so on, are hooked into
+specific parts of the request process. As you are probably aware, modules
+serve different purposes; Some are authentication/authorization handlers,
+others are file or script handlers while some third modules rewrite URIs or
+proxies content. Furthermore, in the end, it is up to the user of the server
+how and when each module will come into place. Thus, the server itself does not
+presume to know which module is responsible for handling a specific
+request, and will ask each module whether they have an interest in a given
+request or not. It is then up to each module to either gently decline
+serving a request, accept serving it or flat out deny the request from
 being served, as authentication/authorization modules do: 
        
 Hook handling in httpd
        
-To make it a bit easier for handlers such as our mod_example to know 
-whether the client is requesting content we should handle or not, the server 
-has directives for hinting to modules whether their assistance is needed or 
-not. Two of these are AddHandler 
-and SetHandler. Let's take a look at 
-an example using AddHandler. In 
-our example case, we want every request ending with .sum to be served by 
-mod_example, so we'll add a configuration directive that tells 
+To make it a bit easier for handlers such as our mod_example to know
+whether the client is requesting content we should handle or not, the server
+has directives for hinting to modules whether their assistance is needed or
+not. Two of these are AddHandler
+and SetHandler. Let's take a look at
+an example using AddHandler. In
+our example case, we want every request ending with .sum to be served by
+mod_example, so we'll add a configuration directive that tells
 the server to do just that:
 
        
 
 AddHandler example-handler ".sum"
 
 
        
-What this tells the server is the following: Whenever we receive a request 
-for a URI ending in .sum, we are to let all modules know that we are 
-looking for whoever goes by the name of "example-handler" . 
-Thus, when a request is being served that ends in .sum, the server will let all 
+What this tells the server is the following: Whenever we receive a request
+for a URI ending in .sum, we are to let all modules know that we are
+looking for whoever goes by the name of "example-handler" .
+Thus, when a request is being served that ends in .sum, the server will let all
 modules know, that this request should be served by "example-handler".
-As you will see later, when we start building mod_example, we will 
-check for this handler tag relayed by AddHandler and reply to 
+As you will see later, when we start building mod_example, we will
+check for this handler tag relayed by AddHandler and reply to
 the server based on the value of this tag.
 
        
 
        
 
        Hooking into httpd
 
        
-To begin with, we only want to create a simple handler, that replies to the 
-client browser when a specific URL is requested, so we won't bother setting 
-up configuration handlers and directives just yet. Our initial module 
+To begin with, we only want to create a simple handler, that replies to the
+client browser when a specific URL is requested, so we won't bother setting
+up configuration handlers and directives just yet. Our initial module
 definition will look like this:
        
 
 
@@ -202,15 +202,15 @@ module AP_MODULE_DECLARE_DATA   example_module =
 
 
 
-
        This lets the server know that we are not interested in anything fancy, we 
-just want to hook onto the requests and possibly handle some of them. 
         
+
        This lets the server know that we are not interested in anything fancy, we
+just want to hook onto the requests and possibly handle some of them. 
        
 
-
         The reference in our example declaration, register_hooks 
-is the name of a function we will create to manage how we hook onto the 
-request process. In this example module, the function has just one purpose; 
-To create a simple hook that gets called after all the rewrites, access 
-control etc has been handled. Thus, we will let the server know, that we want 
-to hook into its process as one of the last modules: 
+
         The reference in our example declaration, register_hooks
+is the name of a function we will create to manage how we hook onto the
+request process. In this example module, the function has just one purpose;
+To create a simple hook that gets called after all the rewrites, access
+control etc has been handled. Thus, we will let the server know, that we want
+to hook into its process as one of the last modules:
 
        
 
 
@@ -224,13 +224,13 @@ static void register_hooks(apr_pool_t *pool)
 
 
 
        
-The example_handler reference is the function that will handle 
+The example_handler reference is the function that will handle
 the request. We will discuss how to create a handler in the next chapter.
 
        
 
        
 
        Other useful hooks
 
        
-Hooking into the request handling phase is but one of many hooks that you 
+Hooking into the request handling phase is but one of many hooks that you
 can create. Some other ways of hooking are:
 
        
 
          
@@ -247,15 +247,15 @@ can create. Some other ways of hooking are:
 
 
          Building a handler
 
          
-A handler is essentially a function that receives a callback when a request 
-to the server is made. It is passed a record of the current request (how it was 
-made, which headers and requests were passed along, who's giving the 
-request and so on), and is put in charge of either telling the server that it's 
+A handler is essentially a function that receives a callback when a request
+to the server is made. It is passed a record of the current request (how it was
+made, which headers and requests were passed along, who's giving the
+request and so on), and is put in charge of either telling the server that it's
 not interested in the request or handle the request with the tools provided.
 
          
-
          A simple "Hello, world!" 
-handler 
-
          Let's start off by making a very simple request handler 
+
          A simple "Hello, world!"
+handler
+
          Let's start off by making a very simple request handler
 that does the following:
 
          
 
            
@@ -277,13 +277,13 @@ static int example_handler(request_rec *r)
      * and the server will try somewhere else.
      */
     if (!r->handler || strcmp(r->handler, "example-handler")) return (DECLINED);
-    
+
     /* Now that we are handling this request, we'll write out "Hello, world!" to the client.
      * To do so, we must first set the appropriate content type, followed by our output.
      */
     ap_set_content_type(r, "text/html");
     ap_rprintf(r, "Hello, world!");
-    
+
     /* Lastly, we must tell the server that we took care of this request and everything went fine.
      * We do so by simply returning the value OK to the server.
      */
@@ -293,19 +293,19 @@ static int example_handler(request_rec *r)
 
 
 
            
-Now, we put all we have learned together and end up with a program that 
-looks like 
+Now, we put all we have learned together and end up with a program that
+looks like
 mod_example_1.c
-. The functions used in this example will be explained later in the section 
-"Some useful functions you should know". 
+. The functions used in this example will be explained later in the section
+"Some useful functions you should know".
 
            
-
           
-
          The request_rec structure 
+
          
+
          The request_rec structure
 
          The most essential part of any request is the request record
 . In a call to a handler function, this is represented by the 
-request_rec*  structure passed along with every call that is made. 
-This struct, typically just referred to as r in modules, 
-contains all the information you need for your module to fully process any 
+request_rec*  structure passed along with every call that is made.
+This struct, typically just referred to as r in modules,
+contains all the information you need for your module to fully process any
 HTTP request and respond accordingly.
           
          Some key elements of the 
 request_rec  structure are:
 
          
@@ -318,12 +318,12 @@ request_rec  structure are:
 
        • r->connection (conn_rec*): A record containing information about the current connection
          • 
 
        • r->user (char*): If the URI requires authentication, this is set to the username provided
          • 
 
        • r->useragent_ip (char*): The IP address of the client connecting to us
          • 
-
        • r->pool (apr_pool_t*): The memory pool of this request. We'll discuss this in the 
+
        • r->pool (apr_pool_t*): The memory pool of this request. We'll discuss this in the
 "Memory management" chapter.
          • 
 
        
 
        
-A complete list of all the values contained within the request_rec structure can be found in 
-the httpd.h header 
+A complete list of all the values contained within the request_rec structure can be found in
+the httpd.h header
 file or at http://ci.apache.org/projects/httpd/trunk/doxygen/structrequest__rec.html.
 
        
 
@@ -341,7 +341,7 @@ static int example_handler(request_rec *r)
 
     /* Print out the IP address of the client connecting to us: */
     ap_rprintf(r, "<h2>Hello, %s!</h2>", r->useragent_ip);
-    
+
     /* If we were reached through a GET or a POST request, be happy, else sad. */
     if ( !strcmp(r->method, "POST") || !strcmp(r->method, "GET") ) {
         ap_rputs("You used a GET or a POST method, that makes us happy!<br/>", r);
@@ -363,11 +363,11 @@ static int example_handler(request_rec *r)
 
 
        Return values
 
        
-Apache relies on return values from handlers to signify whether a request 
-was handled or not, and if so, whether the request went well or not. If a 
-module is not interested in handling a specific request, it should always 
-return the value DECLINED. If it is handling a request, it 
-should either return the generic value OK, or a specific HTTP 
+Apache relies on return values from handlers to signify whether a request
+was handled or not, and if so, whether the request went well or not. If a
+module is not interested in handling a specific request, it should always
+return the value DECLINED. If it is handling a request, it
+should either return the generic value OK, or a specific HTTP
 status code, for example:
 
        
 
@@ -382,13 +382,13 @@ static int example_handler(request_rec *r)
 
 
 
        
-Returning OK or a HTTP status code does not necessarily mean 
-that the request will end. The server may still have other handlers that are 
-interested in this request, for instance the logging modules which, upon a 
-successful request, will write down a summary of what was requested and how 
-it went. To do a full stop and prevent any further processing after your 
-module is done, you can return the value DONE to let the server 
-know that it should cease all activity on this request and carry on with 
+Returning OK or a HTTP status code does not necessarily mean
+that the request will end. The server may still have other handlers that are
+interested in this request, for instance the logging modules which, upon a
+successful request, will write down a summary of what was requested and how
+it went. To do a full stop and prevent any further processing after your
+module is done, you can return the value DONE to let the server
+know that it should cease all activity on this request and carry on with
 the next, without informing other handlers.
 
        
 General response codes:
@@ -416,10 +416,10 @@ the next, without informing other handlers.
 
        
   
@@ -493,9 +493,9 @@
       
        unixd_config
        
       
        This has been renamed to ap_unixd_config.
        
 
-      
        conn_rec->remote_ip and 
+      
        conn_rec->remote_ip and
           conn_rec->remote_addr
        
-      
        These fields have been renamed in order to distinguish between 
+      
        These fields have been renamed in order to distinguish between
       the client IP address of the connection and the useragent IP address
       of the request (potentially overridden by a load balancer or proxy).
       References to either of these fields must be updated with one of the
@@ -509,7 +509,7 @@
         
      • When you require the IP address of the client that is
         connected directly to the server, which might be the useragent or
         might be the load balancer or proxy itself, use
-        conn_rec->client_ip and 
+        conn_rec->client_ip and
         conn_rec->client_addr.
        • 
       
      
       
diff --git a/docs/manual/developer/new_api_2_4.xml b/docs/manual/developer/new_api_2_4.xml
index 179e8fdaf3..b494549757 100644
--- a/docs/manual/developer/new_api_2_4.xml
+++ b/docs/manual/developer/new_api_2_4.xml
@@ -29,7 +29,7 @@
      version 2.2 to 2.4, that may be of interest to module/application
      developers and core hacks.  As of the first GA release of the
      2.4 branch API compatibility is preserved for the life of the
-     2.4 branch.  (The 
+     2.4 branch.  (The
      VERSIONING
      description for the 2.4 release provides more information about API
      compatibility.)
      
@@ -114,9 +114,9 @@
       
    • New API to retain data across module unload/load
      • 
       
    • New check_config hook
      • 
       
    • New ap_process_fnmatch_configs() function to process wildcards
      • 
-      
    • Change ap_configfile_t, ap_cfg_getline(), 
-          ap_cfg_getc() to return error codes, and add 
-          ap_pcfg_strerror() for retrieving an error description.
      •  
+      
    • Change ap_configfile_t, ap_cfg_getline(),
+          ap_cfg_getc() to return error codes, and add
+          ap_pcfg_strerror() for retrieving an error description.
      • 
       
    • Any config directive permitted in ACCESS_CONF context must now
           correctly handle being called from an .htaccess file via the new
           AllowOverrideList directive.
@@ -128,7 +128,7 @@
   
      
     http_core (changed)
     
        
-      
      • REMOVED ap_default_type, ap_requires, all 
+      
      • 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
@@ -156,11 +156,11 @@
       
      • Support for mod_request kept_body
        • 
       
      • Support buffering filter data for async requests
        • 
       
      • New CONN_STATE values
        • 
-      
      • Function changes: ap_escape_html updated; 
+      
      • Function changes: ap_escape_html updated;
           ap_unescape_all, ap_escape_path_segment_buffer
        • 
       
      • Modules that load other modules later than the EXEC_ON_READ config
           reading stage need to call ap_reserve_module_slots() or
-          ap_reserve_module_slots_directive() in their 
+          ap_reserve_module_slots_directive() in their
           pre_config hook.
        • 
       
      • The useragent IP address per request can now be tracked
           independently of the client IP address of the connection, for
@@ -188,16 +188,16 @@
       
      • 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 
+      
      • New flags AP_AUTH_INTERNAL_PER_CONF and
           AP_AUTH_INTERNAL_PER_URI
        • 
-      
      • New access_checker_ex hook to apply additional access control 
+      
      • 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 
+      
      • 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, 
+      
      • 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
@@ -210,7 +210,7 @@
     
      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 
+       control configuration directives, then use
        AP_AUTH_INTERNAL_PER_URI.
      
   
      
 
@@ -221,7 +221,7 @@
 
   
      
     mod_cache (changed)
-    
      Introduces a commit_entity() function to the cache provider 
+    
      Introduces a commit_entity() function to the cache provider
     interface, allowing atomic writes to cache. Add a cache_status()
     hook to report the cache decision. All private structures and functions were
     removed.
      
@@ -262,10 +262,10 @@
           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, timed_callback, and 
+      
    • NEW Hooks: mpm_query, timed_callback, and
           get_name
      • 
       
    • CHANGED interfaces: monitor hook,
-          ap_reclaim_child_processes, 
+          ap_reclaim_child_processes,
           ap_relieve_child_processes
      •
    @@ -490,9 +490,9 @@
    unixd_config
    This has been renamed to ap_unixd_config.
    -
    conn_rec->remote_ip and +
    conn_rec->remote_ip and conn_rec->remote_addr
    -
    These fields have been renamed in order to distinguish between +
    These fields have been renamed in order to distinguish between the client IP address of the connection and the useragent IP address of the request (potentially overridden by a load balancer or proxy). References to either of these fields must be updated with one of the @@ -506,7 +506,7 @@
  • When you require the IP address of the client that is connected directly to the server, which might be the useragent or might be the load balancer or proxy itself, use - conn_rec->client_ip and + conn_rec->client_ip and conn_rec->client_addr.
    • diff --git a/docs/manual/developer/output-filters.html.en b/docs/manual/developer/output-filters.html.en index 8261d9669d..9056b19a20 100644 --- a/docs/manual/developer/output-filters.html.en +++ b/docs/manual/developer/output-filters.html.en @@ -314,10 +314,10 @@ apr_status_t dummy_filter(ap_filter_t *f, apr_bucket_brigade *bb) { struct dummy_state *state; - + state = f->ctx; if (state == NULL) { - + /* First invocation for this response: initialise state structure. */ f->ctx = state = apr_palloc(f->r->pool, sizeof *state); diff --git a/docs/manual/developer/output-filters.xml b/docs/manual/developer/output-filters.xml index 25658e7d69..5ae281f60d 100644 --- a/docs/manual/developer/output-filters.xml +++ b/docs/manual/developer/output-filters.xml @@ -320,10 +320,10 @@ apr_status_t dummy_filter(ap_filter_t *f, apr_bucket_brigade *bb) { struct dummy_state *state; - + state = f->ctx; if (state == NULL) { - + /* First invocation for this response: initialise state structure. */ f->ctx = state = apr_palloc(f->r->pool, sizeof *state); diff --git a/docs/manual/developer/request.html.en b/docs/manual/developer/request.html.en index 9337a8bc6e..d3a44eedfb 100644 --- a/docs/manual/developer/request.html.en +++ b/docs/manual/developer/request.html.en @@ -36,7 +36,7 @@

    The first major change is to the subrequest and redirect mechanisms. There were a number of different code paths in - the Apache HTTP Server 1.3 to attempt to optimize subrequest + the Apache HTTP Server 1.3 to attempt to optimize subrequest or redirect behavior. As patches were introduced to 2.0, these optimizations (and the server behavior) were quickly broken due to this duplication of code. All duplicate code has been folded diff --git a/docs/manual/developer/request.xml b/docs/manual/developer/request.xml index b54e41e3d0..3bc48c27b7 100644 --- a/docs/manual/developer/request.xml +++ b/docs/manual/developer/request.xml @@ -38,7 +38,7 @@

    The first major change is to the subrequest and redirect mechanisms. There were a number of different code paths in - the Apache HTTP Server 1.3 to attempt to optimize subrequest + the Apache HTTP Server 1.3 to attempt to optimize subrequest or redirect behavior. As patches were introduced to 2.0, these optimizations (and the server behavior) were quickly broken due to this duplication of code. All duplicate code has been folded @@ -216,4 +216,3 @@ if ((access_status = ap_run_auth_checker(r)) != 0) { - diff --git a/docs/manual/env.xml.ja b/docs/manual/env.xml.ja index 44474e688e..8379c7feeb 100644 --- a/docs/manual/env.xml.ja +++ b/docs/manual/env.xml.ja @@ -1,7 +1,7 @@ - + + + + diff --git a/docs/manual/glossary.html.en b/docs/manual/glossary.html.en index f55951dfe1..2825b9c8c2 100644 --- a/docs/manual/glossary.html.en +++ b/docs/manual/glossary.html.en @@ -422,8 +422,8 @@

    Subrequest
    Apache provides a subrequest API to modules that allows other filesystem or URL paths to be partially or fully evaluated by - the server. Example consumers of this API are - DirectoryIndex, + the server. Example consumers of this API are + DirectoryIndex, mod_autoindex, and mod_include.
    diff --git a/docs/manual/glossary.xml b/docs/manual/glossary.xml index f8900d5c7e..e8a858faba 100644 --- a/docs/manual/glossary.xml +++ b/docs/manual/glossary.xml @@ -436,8 +436,8 @@
    Subrequest
    Apache provides a subrequest API to modules that allows other filesystem or URL paths to be partially or fully evaluated by - the server. Example consumers of this API are - DirectoryIndex, + the server. Example consumers of this API are + DirectoryIndex, mod_autoindex, and mod_include.
    diff --git a/docs/manual/handler.xml.es b/docs/manual/handler.xml.es index e7b704cb45..64f322c8fb 100644 --- a/docs/manual/handler.xml.es +++ b/docs/manual/handler.xml.es @@ -1,7 +1,7 @@ - + - + + + + + + diff --git a/docs/manual/howto/cgi.xml.fr b/docs/manual/howto/cgi.xml.fr index 1e3425fe11..df463d295b 100644 --- a/docs/manual/howto/cgi.xml.fr +++ b/docs/manual/howto/cgi.xml.fr @@ -1,7 +1,7 @@ - + diff --git a/docs/manual/howto/cgi.xml.ja b/docs/manual/howto/cgi.xml.ja index d92899ceba..b1e1f3466e 100644 --- a/docs/manual/howto/cgi.xml.ja +++ b/docs/manual/howto/cgi.xml.ja @@ -1,7 +1,7 @@ - + + + diff --git a/docs/manual/mod/mod_access_compat.xml.ja b/docs/manual/mod/mod_access_compat.xml.ja index 983688de7d..7a68ebf638 100644 --- a/docs/manual/mod/mod_access_compat.xml.ja +++ b/docs/manual/mod/mod_access_compat.xml.ja @@ -1,7 +1,7 @@ - + + diff --git a/docs/manual/mod/mod_alias.xml.ja b/docs/manual/mod/mod_alias.xml.ja index b961c026a4..066ffa3146 100644 --- a/docs/manual/mod/mod_alias.xml.ja +++ b/docs/manual/mod/mod_alias.xml.ja @@ -1,7 +1,7 @@ - + + + + diff --git a/docs/manual/mod/mod_auth_digest.html.en b/docs/manual/mod/mod_auth_digest.html.en index 6d5a605beb..c72b493d19 100644 --- a/docs/manual/mod/mod_auth_digest.html.en +++ b/docs/manual/mod/mod_auth_digest.html.en @@ -87,7 +87,7 @@ AuthType Digest AuthName "private area" AuthDigestDomain "/private/" "http://mirror.my.dom/private2/" - + AuthDigestProvider file AuthUserFile "/web/auth/.digest_pw" Require valid-user diff --git a/docs/manual/mod/mod_auth_digest.xml b/docs/manual/mod/mod_auth_digest.xml index 7e3382f665..4ec93aacb3 100644 --- a/docs/manual/mod/mod_auth_digest.xml +++ b/docs/manual/mod/mod_auth_digest.xml @@ -68,7 +68,7 @@ AuthType Digest AuthName "private area" AuthDigestDomain "/private/" "http://mirror.my.dom/private2/" - + AuthDigestProvider file AuthUserFile "/web/auth/.digest_pw" Require valid-user diff --git a/docs/manual/mod/mod_authn_anon.html.en b/docs/manual/mod/mod_authn_anon.html.en index ed7c11af71..1322535731 100644 --- a/docs/manual/mod/mod_authn_anon.html.en +++ b/docs/manual/mod/mod_authn_anon.html.en @@ -98,13 +98,13 @@ AuthType Basic AuthBasicProvider file anon AuthUserFile "/path/to/your/.htpasswd" - + Anonymous_NoUserID off Anonymous_MustGiveEmail on Anonymous_VerifyEmail on Anonymous_LogEmail on Anonymous anonymous guest www test welcome - + Require valid-user </Directory> diff --git a/docs/manual/mod/mod_authn_anon.xml b/docs/manual/mod/mod_authn_anon.xml index 778a11504e..330b07a37b 100644 --- a/docs/manual/mod/mod_authn_anon.xml +++ b/docs/manual/mod/mod_authn_anon.xml @@ -86,13 +86,13 @@ AuthType Basic AuthBasicProvider file anon AuthUserFile "/path/to/your/.htpasswd" - + Anonymous_NoUserID off Anonymous_MustGiveEmail on Anonymous_VerifyEmail on Anonymous_LogEmail on Anonymous anonymous guest www test welcome - + Require valid-user </Directory> diff --git a/docs/manual/mod/mod_authn_core.html.en b/docs/manual/mod/mod_authn_core.html.en index 4192656142..05d6e09c41 100644 --- a/docs/manual/mod/mod_authn_core.html.en +++ b/docs/manual/mod/mod_authn_core.html.en @@ -74,13 +74,13 @@ </AuthnProviderAlias> # Then check here -<AuthnProviderAlias file file2> +<AuthnProviderAlias file file2> AuthUserFile "/www/conf/passwords2" </AuthnProviderAlias> <Directory "/var/web/pages/secure"> AuthBasicProvider file1 file2 - + AuthType Basic AuthName "Protected Area" Require valid-user @@ -107,13 +107,13 @@ Alias "/secure" "/webpages/secure" <Directory "/webpages/secure"> Order deny,allow Allow from all - + AuthBasicProvider ldap-other-alias ldap-alias1 - + AuthType Basic AuthName "LDAP Protected Place" Require valid-user - # Note that Require ldap-* would not work here, since the + # Note that Require ldap-* would not work here, since the # AuthnProviderAlias does not provide the config to authorization providers # that are implemented in the same module as the authentication provider. </Directory> diff --git a/docs/manual/mod/mod_authn_core.xml b/docs/manual/mod/mod_authn_core.xml index 3c349d73a6..97a00ee49b 100644 --- a/docs/manual/mod/mod_authn_core.xml +++ b/docs/manual/mod/mod_authn_core.xml @@ -61,13 +61,13 @@ </AuthnProviderAlias> # Then check here -<AuthnProviderAlias file file2> +<AuthnProviderAlias file file2> AuthUserFile "/www/conf/passwords2" </AuthnProviderAlias> <Directory "/var/web/pages/secure"> AuthBasicProvider file1 file2 - + AuthType Basic AuthName "Protected Area" Require valid-user @@ -97,13 +97,13 @@ Alias "/secure" "/webpages/secure" <Directory "/webpages/secure"> Order deny,allow Allow from all - + AuthBasicProvider ldap-other-alias ldap-alias1 - + AuthType Basic AuthName "LDAP Protected Place" Require valid-user - # Note that Require ldap-* would not work here, since the + # Note that Require ldap-* would not work here, since the # AuthnProviderAlias does not provide the config to authorization providers # that are implemented in the same module as the authentication provider. </Directory> diff --git a/docs/manual/mod/mod_authn_socache.xml.fr b/docs/manual/mod/mod_authn_socache.xml.fr index 3e682bb48f..b7b0606a49 100644 --- a/docs/manual/mod/mod_authn_socache.xml.fr +++ b/docs/manual/mod/mod_authn_socache.xml.fr @@ -1,7 +1,7 @@ - + diff --git a/docs/manual/mod/mod_authz_core.html.en b/docs/manual/mod/mod_authz_core.html.en index a9eb23b231..a3d289cab8 100644 --- a/docs/manual/mod/mod_authz_core.html.en +++ b/docs/manual/mod/mod_authz_core.html.en @@ -135,12 +135,12 @@ with KnockKnock/2.0 will be allowed access, and all others will be denied.

    -

    When the server looks up a path via an internal - subrequest such as looking - for a DirectoryIndex +

    When the server looks up a path via an internal + subrequest such as looking + for a DirectoryIndex or generating a directory listing with mod_autoindex, - per-request environment variables are not inherited in the - subrequest. Additionally, + per-request environment variables are not inherited in the + subrequest. Additionally, SetEnvIf directives are not separately evaluated in the subrequest due to the API phases mod_setenvif takes action in.

    @@ -198,7 +198,7 @@ 
    <RequireAll>
     Require expr "!(%{QUERY_STRING} =~ /secret/)"
-    Require expr "%{REQUEST_URI} in { '/example.cgi', '/other.cgi' }" 
+    Require expr "%{REQUEST_URI} in { '/example.cgi', '/other.cgi' }"
 </RequireAll>
    diff --git a/docs/manual/mod/mod_authz_core.xml b/docs/manual/mod/mod_authz_core.xml index 26c3ce2df6..57001b9bd0 100644 --- a/docs/manual/mod/mod_authz_core.xml +++ b/docs/manual/mod/mod_authz_core.xml @@ -117,12 +117,12 @@ SetEnvIf User-Agent "^KnockKnock/2\.0" let_me_in with KnockKnock/2.0 will be allowed access, and all others will be denied.

    -

    When the server looks up a path via an internal - subrequest such as looking - for a DirectoryIndex +

    When the server looks up a path via an internal + subrequest such as looking + for a DirectoryIndex or generating a directory listing with mod_autoindex, - per-request environment variables are not inherited in the - subrequest. Additionally, + per-request environment variables are not inherited in the + subrequest. Additionally, SetEnvIf directives are not separately evaluated in the subrequest due to the API phases mod_setenvif takes action in.

    @@ -186,12 +186,12 @@ SetEnvIf User-Agent "^KnockKnock/2\.0" let_me_in <RequireAll> Require expr "!(%{QUERY_STRING} =~ /secret/)" - Require expr "%{REQUEST_URI} in { '/example.cgi', '/other.cgi' }" + Require expr "%{REQUEST_URI} in { '/example.cgi', '/other.cgi' }" </RequireAll> - Require expr "!(%{QUERY_STRING} =~ /secret/) && %{REQUEST_URI} in { '/example.cgi', '/other.cgi' }" + Require expr "!(%{QUERY_STRING} =~ /secret/) && %{REQUEST_URI} in { '/example.cgi', '/other.cgi' }"

    The syntax is described in the ap_expr diff --git a/docs/manual/mod/mod_autoindex.xml.fr b/docs/manual/mod/mod_autoindex.xml.fr index 92fe7e695b..56c62df93d 100644 --- a/docs/manual/mod/mod_autoindex.xml.fr +++ b/docs/manual/mod/mod_autoindex.xml.fr @@ -1,7 +1,7 @@ - + diff --git a/docs/manual/mod/mod_autoindex.xml.ja b/docs/manual/mod/mod_autoindex.xml.ja index a0421c4f51..f8a07469ef 100644 --- a/docs/manual/mod/mod_autoindex.xml.ja +++ b/docs/manual/mod/mod_autoindex.xml.ja @@ -1,7 +1,7 @@ - + + + + diff --git a/docs/manual/mod/mod_cache.xml.ja b/docs/manual/mod/mod_cache.xml.ja index c8dee0feb5..af80c0284b 100644 --- a/docs/manual/mod/mod_cache.xml.ja +++ b/docs/manual/mod/mod_cache.xml.ja @@ -1,7 +1,7 @@ - + + + diff --git a/docs/manual/mod/mod_deflate.xml.ja b/docs/manual/mod/mod_deflate.xml.ja index 65bba7d667..b3658a3e2e 100644 --- a/docs/manual/mod/mod_deflate.xml.ja +++ b/docs/manual/mod/mod_deflate.xml.ja @@ -1,7 +1,7 @@ - + + + diff --git a/docs/manual/mod/mod_dir.xml.fr b/docs/manual/mod/mod_dir.xml.fr index ffe345a2dd..4d156a493c 100644 --- a/docs/manual/mod/mod_dir.xml.fr +++ b/docs/manual/mod/mod_dir.xml.fr @@ -1,7 +1,7 @@ - + diff --git a/docs/manual/mod/mod_dir.xml.ja b/docs/manual/mod/mod_dir.xml.ja index 59c3c675a1..4e7c2d82bf 100644 --- a/docs/manual/mod/mod_dir.xml.ja +++ b/docs/manual/mod/mod_dir.xml.ja @@ -1,7 +1,7 @@ - + + + + diff --git a/docs/manual/mod/mod_ext_filter.xml.ja b/docs/manual/mod/mod_ext_filter.xml.ja index ba8222eeb8..be3a9ee1ce 100644 --- a/docs/manual/mod/mod_ext_filter.xml.ja +++ b/docs/manual/mod/mod_ext_filter.xml.ja @@ -1,7 +1,7 @@ - + + @@ -339,7 +339,7 @@ AddOutputFilter INCLUDES .shtml The value of file cannot start with a slash - (/), nor can it contain ../ so as to + (/), nor can it contain ../ so as to refer to a file above the current directory or outside of the document root. Attempting to so will result in the error message: The given path was above the root path. @@ -1072,4 +1072,3 @@ set - diff --git a/docs/manual/mod/mod_lbmethod_heartbeat.html.en b/docs/manual/mod/mod_lbmethod_heartbeat.html.en index dd7cd819e2..82b3f20fb6 100644 --- a/docs/manual/mod/mod_lbmethod_heartbeat.html.en +++ b/docs/manual/mod/mod_lbmethod_heartbeat.html.en @@ -37,8 +37,8 @@ heartbeat info via the mod_heartbeat module.

    This modules load balancing algorithm favors servers with more ready (idle) -capacity over time, but does not select the server with the most ready capacity -every time. Servers that have 0 active clients are penalized, with the +capacity over time, but does not select the server with the most ready capacity +every time. Servers that have 0 active clients are penalized, with the assumption that they are not fully initialized.

    Directives

    diff --git a/docs/manual/mod/mod_lbmethod_heartbeat.xml b/docs/manual/mod/mod_lbmethod_heartbeat.xml index 9dd28f0012..3fe7f20877 100644 --- a/docs/manual/mod/mod_lbmethod_heartbeat.xml +++ b/docs/manual/mod/mod_lbmethod_heartbeat.xml @@ -36,8 +36,8 @@ heartbeat info via the mod_heartbeat module.

    This modules load balancing algorithm favors servers with more ready (idle) -capacity over time, but does not select the server with the most ready capacity -every time. Servers that have 0 active clients are penalized, with the +capacity over time, but does not select the server with the most ready capacity +every time. Servers that have 0 active clients are penalized, with the assumption that they are not fully initialized.

    diff --git a/docs/manual/mod/mod_ldap.xml.fr b/docs/manual/mod/mod_ldap.xml.fr index c7e71c0879..6c555fcce7 100644 --- a/docs/manual/mod/mod_ldap.xml.fr +++ b/docs/manual/mod/mod_ldap.xml.fr @@ -1,7 +1,7 @@ - + diff --git a/docs/manual/mod/mod_log_config.xml.ja b/docs/manual/mod/mod_log_config.xml.ja index 6052003aef..8736149d80 100644 --- a/docs/manual/mod/mod_log_config.xml.ja +++ b/docs/manual/mod/mod_log_config.xml.ja @@ -1,7 +1,7 @@ - + + + + diff --git a/docs/manual/mod/mod_macro.xml.fr b/docs/manual/mod/mod_macro.xml.fr index bb45eaa84c..4b2a1d3f61 100644 --- a/docs/manual/mod/mod_macro.xml.fr +++ b/docs/manual/mod/mod_macro.xml.fr @@ -1,7 +1,7 @@ - + diff --git a/docs/manual/mod/mod_proxy_ajp.xml.ja b/docs/manual/mod/mod_proxy_ajp.xml.ja index 78ff290740..8fdefce515 100644 --- a/docs/manual/mod/mod_proxy_ajp.xml.ja +++ b/docs/manual/mod/mod_proxy_ajp.xml.ja @@ -1,7 +1,7 @@ - + + diff --git a/docs/manual/mod/mod_sed.html.en b/docs/manual/mod/mod_sed.html.en index e3c104e3c2..902d0c35e8 100644 --- a/docs/manual/mod/mod_sed.html.en +++ b/docs/manual/mod/mod_sed.html.en @@ -78,20 +78,20 @@ the author's blog.

    Adding an output filter 

    # In the following example, the sed filter will change the string
 # "monday" to "MON" and the string "sunday" to SUN in html documents
 # before sending to the client.
-<Directory "/var/www/docs/sed"> 
-    AddOutputFilter Sed html 
-    OutputSed "s/monday/MON/g" 
-    OutputSed "s/sunday/SUN/g" 
+<Directory "/var/www/docs/sed">
+    AddOutputFilter Sed html
+    OutputSed "s/monday/MON/g"
+    OutputSed "s/sunday/SUN/g"
 </Directory>

    Adding an input filter 

    # In the following example, the sed filter will change the string
 # "monday" to "MON" and the string "sunday" to SUN in the POST data
 # sent to PHP.
-<Directory "/var/www/docs/sed"> 
-    AddInputFilter Sed php 
-    InputSed "s/monday/MON/g" 
-    InputSed "s/sunday/SUN/g" 
+<Directory "/var/www/docs/sed">
+    AddInputFilter Sed php
+    InputSed "s/monday/MON/g"
+    InputSed "s/sunday/SUN/g"
 </Directory>
    top
    diff --git a/docs/manual/mod/mod_sed.xml b/docs/manual/mod/mod_sed.xml index 639a909d5e..be201d7b4a 100644 --- a/docs/manual/mod/mod_sed.xml +++ b/docs/manual/mod/mod_sed.xml @@ -66,11 +66,11 @@ the author's blog.

    # In the following example, the sed filter will change the string # "monday" to "MON" and the string "sunday" to SUN in html documents # before sending to the client. -<Directory "/var/www/docs/sed"> - AddOutputFilter Sed html - OutputSed "s/monday/MON/g" - OutputSed "s/sunday/SUN/g" -</Directory> +<Directory "/var/www/docs/sed"> + AddOutputFilter Sed html + OutputSed "s/monday/MON/g" + OutputSed "s/sunday/SUN/g" +</Directory> @@ -79,11 +79,11 @@ the author's blog.

    # In the following example, the sed filter will change the string # "monday" to "MON" and the string "sunday" to SUN in the POST data # sent to PHP. -<Directory "/var/www/docs/sed"> - AddInputFilter Sed php - InputSed "s/monday/MON/g" - InputSed "s/sunday/SUN/g" -</Directory> +<Directory "/var/www/docs/sed"> + AddInputFilter Sed php + InputSed "s/monday/MON/g" + InputSed "s/sunday/SUN/g" +</Directory> diff --git a/docs/manual/mod/mod_session.html.en b/docs/manual/mod/mod_session.html.en index 40a25840e7..7cb2aee67f 100644 --- a/docs/manual/mod/mod_session.html.en +++ b/docs/manual/mod/mod_session.html.en @@ -322,7 +322,7 @@ AuthName "realm" session from or writing the session to the chosen storage mechanism is handled by the mod_session modules and corresponding configuration. - +
    Applications behind mod_proxy
    If the SessionHeader directive is used to define an HTTP request header, the session, encoded as @@ -332,7 +332,7 @@ AuthName "realm" above, any encryption or decryption, and the reading the session from or writing the session to the chosen storage mechanism is handled by the mod_session modules and corresponding configuration.
    - +
    Standalone applications
    Applications might choose to manipulate the session outside the control of the Apache HTTP server. In this case, it is the responsibility of the diff --git a/docs/manual/mod/mod_session.xml b/docs/manual/mod/mod_session.xml index b6142517aa..d5e67ca5e6 100644 --- a/docs/manual/mod/mod_session.xml +++ b/docs/manual/mod/mod_session.xml @@ -310,7 +310,7 @@ AuthName "realm" session from or writing the session to the chosen storage mechanism is handled by the mod_session modules and corresponding configuration.
    - +
    Applications behind mod_proxy
    If the SessionHeader directive is used to define an HTTP request header, the session, encoded as @@ -320,7 +320,7 @@ AuthName "realm" above, any encryption or decryption, and the reading the session from or writing the session to the chosen storage mechanism is handled by the mod_session modules and corresponding configuration.
    - +
    Standalone applications
    Applications might choose to manipulate the session outside the control of the Apache HTTP server. In this case, it is the responsibility of the diff --git a/docs/manual/mod/mod_setenvif.html.en b/docs/manual/mod/mod_setenvif.html.en index 4599961c42..817b8d23f2 100644 --- a/docs/manual/mod/mod_setenvif.html.en +++ b/docs/manual/mod/mod_setenvif.html.en @@ -54,12 +54,12 @@ on characteristics of the request BrowserMatch MSIE !netscape -

    When the server looks up a path via an internal - subrequest such as looking - for a DirectoryIndex +

    When the server looks up a path via an internal + subrequest such as looking + for a DirectoryIndex or generating a directory listing with mod_autoindex, - per-request environment variables are not inherited in the - subrequest. Additionally, + per-request environment variables are not inherited in the + subrequest. Additionally, SetEnvIf directives are not separately evaluated in the subrequest due to the API phases mod_setenvif takes action in.

    @@ -230,11 +230,11 @@ of

    SetEnvIf Request_URI "\.gif$" object_is_image=gif
 SetEnvIf Request_URI "\.jpg$" object_is_image=jpg
 SetEnvIf Request_URI "\.xbm$" object_is_image=xbm
-    
+
 SetEnvIf Referer www\.mydomain\.example\.com intra_site_referral
-    
+
 SetEnvIf object_is_image xbm XBIT_PROCESSING=1
-    
+
 SetEnvIf ^TS  ^[a-z]  HAVE_TS
    diff --git a/docs/manual/mod/mod_setenvif.xml b/docs/manual/mod/mod_setenvif.xml index 2276091a2a..1b0d9ca7be 100644 --- a/docs/manual/mod/mod_setenvif.xml +++ b/docs/manual/mod/mod_setenvif.xml @@ -49,12 +49,12 @@ BrowserMatch ^Mozilla netscape BrowserMatch MSIE !netscape -

    When the server looks up a path via an internal - subrequest such as looking - for a DirectoryIndex +

    When the server looks up a path via an internal + subrequest such as looking + for a DirectoryIndex or generating a directory listing with mod_autoindex, - per-request environment variables are not inherited in the - subrequest. Additionally, + per-request environment variables are not inherited in the + subrequest. Additionally, SetEnvIf directives are not separately evaluated in the subrequest due to the API phases mod_setenvif takes action in.

    @@ -226,11 +226,11 @@ of

    SetEnvIf Request_URI "\.gif$" object_is_image=gif SetEnvIf Request_URI "\.jpg$" object_is_image=jpg SetEnvIf Request_URI "\.xbm$" object_is_image=xbm - + SetEnvIf Referer www\.mydomain\.example\.com intra_site_referral - + SetEnvIf object_is_image xbm XBIT_PROCESSING=1 - + SetEnvIf ^TS ^[a-z] HAVE_TS diff --git a/docs/manual/mod/mod_slotmem_plain.html.en b/docs/manual/mod/mod_slotmem_plain.html.en index b1b8516371..4d8d5052b9 100644 --- a/docs/manual/mod/mod_slotmem_plain.html.en +++ b/docs/manual/mod/mod_slotmem_plain.html.en @@ -75,7 +75,7 @@
    apr_status_t fgrab(ap_slotmem_instance_t *s, unsigned int item_id);
    forced grab or allocate the specified slot and mark as in-use (does not do any data copying)
    - +
    apr_status_t release(ap_slotmem_instance_t *s, unsigned int item_id);
    release or free a slot and mark as not in-use (does not do any data copying)
    diff --git a/docs/manual/mod/mod_slotmem_plain.xml b/docs/manual/mod/mod_slotmem_plain.xml index 6cd8fe5842..e7ccc39d3a 100644 --- a/docs/manual/mod/mod_slotmem_plain.xml +++ b/docs/manual/mod/mod_slotmem_plain.xml @@ -72,7 +72,7 @@
    apr_status_t fgrab(ap_slotmem_instance_t *s, unsigned int item_id);
    forced grab or allocate the specified slot and mark as in-use (does not do any data copying)
    - +
    apr_status_t release(ap_slotmem_instance_t *s, unsigned int item_id);
    release or free a slot and mark as not in-use (does not do any data copying)
    diff --git a/docs/manual/mod/mod_socache_dbm.html.en b/docs/manual/mod/mod_socache_dbm.html.en index 85624bac2d..72b2fea7c7 100644 --- a/docs/manual/mod/mod_socache_dbm.html.en +++ b/docs/manual/mod/mod_socache_dbm.html.en @@ -36,7 +36,7 @@ which provides for creation and access to a cache backed by a DBM database.

    - +

    dbm:/path/to/datafile

    diff --git a/docs/manual/mod/mod_socache_dbm.xml b/docs/manual/mod/mod_socache_dbm.xml index bd627f08eb..518453c8de 100644 --- a/docs/manual/mod/mod_socache_dbm.xml +++ b/docs/manual/mod/mod_socache_dbm.xml @@ -33,7 +33,7 @@ which provides for creation and access to a cache backed by a DBM database.

    - + dbm:/path/to/datafile diff --git a/docs/manual/mod/mod_socache_memcache.html.en b/docs/manual/mod/mod_socache_memcache.html.en index 35799cb2a1..4b127ec946 100644 --- a/docs/manual/mod/mod_socache_memcache.html.en +++ b/docs/manual/mod/mod_socache_memcache.html.en @@ -38,16 +38,16 @@ high-performance, distributed memory object caching system.

    - -

    This shared object cache provider's "create" method requires a + +

    This shared object cache provider's "create" method requires a comma separated list of memcached host/port specifications. If using - this provider via another modules configuration (such as + this provider via another modules configuration (such as SSLSessionCache), provide the list of servers as the optional "arg" parameter.

    SSLSessionCache memcache:memcache.example.com:12345,memcache2.example.com:12345
    - +

    Details of other shared object cache providers can be found here.

    diff --git a/docs/manual/mod/mod_socache_memcache.xml b/docs/manual/mod/mod_socache_memcache.xml index a25a39be91..c6c0163a41 100644 --- a/docs/manual/mod/mod_socache_memcache.xml +++ b/docs/manual/mod/mod_socache_memcache.xml @@ -35,17 +35,17 @@ high-performance, distributed memory object caching system.

    - -

    This shared object cache provider's "create" method requires a + +

    This shared object cache provider's "create" method requires a comma separated list of memcached host/port specifications. If using - this provider via another modules configuration (such as + this provider via another modules configuration (such as SSLSessionCache), provide the list of servers as the optional "arg" parameter.

    SSLSessionCache memcache:memcache.example.com:12345,memcache2.example.com:12345 - +

    Details of other shared object cache providers can be found here.

    diff --git a/docs/manual/mod/mod_socache_shmcb.html.en b/docs/manual/mod/mod_socache_shmcb.html.en index 2359d4c7b0..fb4025223e 100644 --- a/docs/manual/mod/mod_socache_shmcb.html.en +++ b/docs/manual/mod/mod_socache_shmcb.html.en @@ -36,7 +36,7 @@ which provides for creation and access to a cache backed by a high-performance cyclic buffer inside a shared memory segment.

    - +

    shmcb:/path/to/datafile(512000)

    diff --git a/docs/manual/mod/mod_socache_shmcb.xml b/docs/manual/mod/mod_socache_shmcb.xml index 7ee9c96042..22d01716e1 100644 --- a/docs/manual/mod/mod_socache_shmcb.xml +++ b/docs/manual/mod/mod_socache_shmcb.xml @@ -33,7 +33,7 @@ which provides for creation and access to a cache backed by a high-performance cyclic buffer inside a shared memory segment.

    - + shmcb:/path/to/datafile(512000) diff --git a/docs/manual/mod/mod_ssl_ct.html.en b/docs/manual/mod/mod_ssl_ct.html.en index 98e77f39b5..61ec477613 100644 --- a/docs/manual/mod/mod_ssl_ct.html.en +++ b/docs/manual/mod/mod_ssl_ct.html.en @@ -34,7 +34,7 @@

    Summary

    -

    This module provides an implementation of Certificate Transparency, in +

    This module provides an implementation of Certificate Transparency, in conjunction with mod_ssl and command-line tools from the certificate-transparency open source project. The goal of Certificate Transparency is to expose the @@ -63,11 +63,11 @@ this documentation:

    servers and proxies:

      -
    • Signed Certificate Timestamps (SCTs) can be obtained from logs +
    • Signed Certificate Timestamps (SCTs) can be obtained from logs automatically and, in conjunction with any statically configured SCTs, sent to aware clients in the ServerHello (during the handshake).
    • SCTs can be received by the proxy from origin servers in the ServerHello, - in a certificate extension, and/or within stapled OCSP responses; any SCTs + in a certificate extension, and/or within stapled OCSP responses; any SCTs received can be partially validated on-line and optionally queued for off-line audit.
    • The proxy can be configured to disallow communication with an origin @@ -161,7 +161,7 @@ testing.

    If verification fails for at least one SCT and verification was not - successful for at least one SCT, the connection is aborted if + successful for at least one SCT, the connection is aborted if CTProxyAwareness is set to require.

    @@ -223,7 +223,7 @@ testing.

    log URL
    The URL of the log (for its API) is required by a server in order to submit server certificates to the log. The server will submit - each server certificate in order to obtain an SCT for each log with a + each server certificate in order to obtain an SCT for each log with a configured URL, except when the log is also marked as distrusted or the current time is not within any configured valid timestamp range.
    @@ -232,7 +232,7 @@ testing.

    Generally, only a small subset of this information is configured for a - particular log. Refer to the documentation for the CTStaticLogConfig directive and the + particular log. Refer to the documentation for the CTStaticLogConfig directive and the ctlogconfig command for more specific information.

    top
    @@ -246,7 +246,7 @@ testing.

    Sample code in the form of a Python script to build an SCT in the correct format from data received from a log can be found in - Tom Ritter's ct-tools + Tom Ritter's ct-tools repository. Refer to write-sct.py

    top
    @@ -314,7 +314,7 @@ testing.

    The directory will contain files named PID.tmp for active child processes and files named PID.out for exited - child processes. These .out files are ready for off-line audit. + child processes. These .out files are ready for off-line audit. The experimental command ctauditscts (in the httpd source tree, not currently installed) interfaces with certificate-transparency tools to perform the audit.

    @@ -432,7 +432,7 @@ refreshed to that certificate; the name of the subdirectory is the SHA-256 hash of the certificate.

    -

    The certificate-specific directory contains SCTs retrieved from configured +

    The certificate-specific directory contains SCTs retrieved from configured logs, SCT lists prepared from statically configured SCTs and retrieved SCTs, and other information used for managing SCTs.

    @@ -473,7 +473,7 @@ ServerHello

    This directive is used to configure information about a particular log. This directive is appropriate when configuration information changes rarely. - If dynamic configuration updates must be supported, refer to the + If dynamic configuration updates must be supported, refer to the CTLogConfigDB directive.

    Each of the six fields must be specified, but usually only a small @@ -509,7 +509,7 @@ ServerHello Timestamps. This must be provided as a decimal number.
    Specify - for one of the timestamps if it is unknown. - For example, when configuring the minimum valid timestamp for a log which remains + For example, when configuring the minimum valid timestamp for a log which remains valid, specify - for max-timestamp.
    SCTs received from this log by the proxy are invalid if the timestamp @@ -549,7 +549,7 @@ about the fields which can be configured with this directive.

    • sct-directory should contain one or more files with extension .sct, representing one or more SCTs corresponding to the - server certificate. If sct-directory is not absolute, then it is + server certificate. If sct-directory is not absolute, then it is assumed to be relative to ServerRoot.

    If sct-directory is empty, no error will be raised.

    diff --git a/docs/manual/mod/mod_ssl_ct.xml b/docs/manual/mod/mod_ssl_ct.xml index 4f95e6fe03..75f36e781f 100644 --- a/docs/manual/mod/mod_ssl_ct.xml +++ b/docs/manual/mod/mod_ssl_ct.xml @@ -31,7 +31,7 @@ -

    This module provides an implementation of Certificate Transparency, in +

    This module provides an implementation of Certificate Transparency, in conjunction with mod_ssl and command-line tools from the certificate-transparency open source project. The goal of Certificate Transparency is to expose the @@ -60,11 +60,11 @@ this documentation:

    servers and proxies:

      -
    • Signed Certificate Timestamps (SCTs) can be obtained from logs +
    • Signed Certificate Timestamps (SCTs) can be obtained from logs automatically and, in conjunction with any statically configured SCTs, sent to aware clients in the ServerHello (during the handshake).
    • SCTs can be received by the proxy from origin servers in the ServerHello, - in a certificate extension, and/or within stapled OCSP responses; any SCTs + in a certificate extension, and/or within stapled OCSP responses; any SCTs received can be partially validated on-line and optionally queued for off-line audit.
    • The proxy can be configured to disallow communication with an origin @@ -136,7 +136,7 @@ testing.

    If verification fails for at least one SCT and verification was not - successful for at least one SCT, the connection is aborted if + successful for at least one SCT, the connection is aborted if CTProxyAwareness is set to require.

    @@ -199,7 +199,7 @@ testing.

    log URL
    The URL of the log (for its API) is required by a server in order to submit server certificates to the log. The server will submit - each server certificate in order to obtain an SCT for each log with a + each server certificate in order to obtain an SCT for each log with a configured URL, except when the log is also marked as distrusted or the current time is not within any configured valid timestamp range.
    @@ -208,8 +208,8 @@ testing.

    Generally, only a small subset of this information is configured for a - particular log. Refer to the documentation for the CTStaticLogConfig directive and the + particular log. Refer to the documentation for the CTStaticLogConfig directive and the ctlogconfig command for more specific information.

    @@ -223,7 +223,7 @@ testing.

    Sample code in the form of a Python script to build an SCT in the correct format from data received from a log can be found in - Tom Ritter's ct-tools + Tom Ritter's ct-tools repository. Refer to write-sct.py

    @@ -290,7 +290,7 @@ testing.

    The directory will contain files named PID.tmp for active child processes and files named PID.out for exited - child processes. These .out files are ready for off-line audit. + child processes. These .out files are ready for off-line audit. The experimental command ctauditscts (in the httpd source tree, not currently installed) interfaces with certificate-transparency tools to perform the audit.

    @@ -406,7 +406,7 @@ refreshed to that certificate; the name of the subdirectory is the SHA-256 hash of the certificate.

    -

    The certificate-specific directory contains SCTs retrieved from configured +

    The certificate-specific directory contains SCTs retrieved from configured logs, SCT lists prepared from statically configured SCTs and retrieved SCTs, and other information used for managing SCTs.

    @@ -447,7 +447,7 @@ ServerHello

    This directive is used to configure information about a particular log. This directive is appropriate when configuration information changes rarely. - If dynamic configuration updates must be supported, refer to the + If dynamic configuration updates must be supported, refer to the CTLogConfigDB directive.

    Each of the six fields must be specified, but usually only a small @@ -483,7 +483,7 @@ ServerHello Timestamps. This must be provided as a decimal number.
    Specify - for one of the timestamps if it is unknown. - For example, when configuring the minimum valid timestamp for a log which remains + For example, when configuring the minimum valid timestamp for a log which remains valid, specify - for max-timestamp.
    SCTs received from this log by the proxy are invalid if the timestamp @@ -522,7 +522,7 @@ about the fields which can be configured with this directive.

    sct-directory should contain one or more files with extension .sct, representing one or more SCTs corresponding to the - server certificate. If sct-directory is not absolute, then it is + server certificate. If sct-directory is not absolute, then it is assumed to be relative to ServerRoot.

    If sct-directory is empty, no error will be raised.

    diff --git a/docs/manual/mod/mod_status.xml.fr b/docs/manual/mod/mod_status.xml.fr index c956e13d7f..713b2d375c 100644 --- a/docs/manual/mod/mod_status.xml.fr +++ b/docs/manual/mod/mod_status.xml.fr @@ -1,7 +1,7 @@ - + diff --git a/docs/manual/mod/mod_status.xml.ja b/docs/manual/mod/mod_status.xml.ja index 565237a31d..9b9c18cc35 100644 --- a/docs/manual/mod/mod_status.xml.ja +++ b/docs/manual/mod/mod_status.xml.ja @@ -2,7 +2,7 @@ - + + + + + + diff --git a/docs/manual/rewrite/index.html.fr b/docs/manual/rewrite/index.html.fr index e809f69feb..c02a7a3f19 100644 --- a/docs/manual/rewrite/index.html.fr +++ b/docs/manual/rewrite/index.html.fr @@ -26,6 +26,8 @@  tr  |  zh-cn 

    +
    Cette traduction peut être périmée. Vérifiez la version + anglaise pour les changements récents.

    mod_rewrite permet de modifier les requêtes diff --git a/docs/manual/rewrite/index.xml.fr b/docs/manual/rewrite/index.xml.fr index de2ac216ea..75eb69c41d 100644 --- a/docs/manual/rewrite/index.xml.fr +++ b/docs/manual/rewrite/index.xml.fr @@ -1,7 +1,7 @@ - + diff --git a/docs/manual/rewrite/index.xml.meta b/docs/manual/rewrite/index.xml.meta index 25046eafe9..96567025f0 100644 --- a/docs/manual/rewrite/index.xml.meta +++ b/docs/manual/rewrite/index.xml.meta @@ -8,7 +8,7 @@ en - fr + fr tr zh-cn diff --git a/docs/manual/rewrite/index.xml.tr b/docs/manual/rewrite/index.xml.tr index dd52f20fc4..122d16af0a 100644 --- a/docs/manual/rewrite/index.xml.tr +++ b/docs/manual/rewrite/index.xml.tr @@ -1,7 +1,7 @@ - + + + diff --git a/docs/manual/rewrite/intro.xml.meta b/docs/manual/rewrite/intro.xml.meta index 5aaac0fc86..ce245b2841 100644 --- a/docs/manual/rewrite/intro.xml.meta +++ b/docs/manual/rewrite/intro.xml.meta @@ -8,6 +8,6 @@ en - fr + fr diff --git a/docs/manual/rewrite/tech.html.fr b/docs/manual/rewrite/tech.html.fr index 198dc56162..67a5448a54 100644 --- a/docs/manual/rewrite/tech.html.fr +++ b/docs/manual/rewrite/tech.html.fr @@ -24,6 +24,8 @@

    Langues Disponibles:  en  |  fr 

    +
    Cette traduction peut être périmée. Vérifiez la version + anglaise pour les changements récents.

    Ce document passe en revue certains détails techniques à propos du module mod_rewrite et de la mise en correspondance des URLs

    diff --git a/docs/manual/rewrite/tech.xml.fr b/docs/manual/rewrite/tech.xml.fr index efb23ac4fd..4d9858ba0f 100644 --- a/docs/manual/rewrite/tech.xml.fr +++ b/docs/manual/rewrite/tech.xml.fr @@ -1,7 +1,7 @@ - + diff --git a/docs/manual/rewrite/tech.xml.meta b/docs/manual/rewrite/tech.xml.meta index 09c2c39746..f8fb2f4fda 100644 --- a/docs/manual/rewrite/tech.xml.meta +++ b/docs/manual/rewrite/tech.xml.meta @@ -8,6 +8,6 @@ en - fr + fr diff --git a/docs/manual/sections.xml.fr b/docs/manual/sections.xml.fr index 11088af6f8..b2ccf2175f 100644 --- a/docs/manual/sections.xml.fr +++ b/docs/manual/sections.xml.fr @@ -3,7 +3,7 @@ - + + + + + diff --git a/docs/manual/ssl/ssl_faq.xml.meta b/docs/manual/ssl/ssl_faq.xml.meta index 61db826966..a5d5a97804 100644 --- a/docs/manual/ssl/ssl_faq.xml.meta +++ b/docs/manual/ssl/ssl_faq.xml.meta @@ -8,6 +8,6 @@ en - fr + fr diff --git a/docs/manual/ssl/ssl_howto.xml.fr b/docs/manual/ssl/ssl_howto.xml.fr index a898641ff0..a937496315 100644 --- a/docs/manual/ssl/ssl_howto.xml.fr +++ b/docs/manual/ssl/ssl_howto.xml.fr @@ -1,7 +1,7 @@ - + diff --git a/docs/manual/suexec.html.fr b/docs/manual/suexec.html.fr index 32bed3ea3a..0af741b807 100644 --- a/docs/manual/suexec.html.fr +++ b/docs/manual/suexec.html.fr @@ -27,6 +27,8 @@  ko  |  tr 

    +
    Cette traduction peut être périmée. Vérifiez la version + anglaise pour les changements récents.

    La fonctionnalité suEXEC permet l'exécution des programmes CGI et diff --git a/docs/manual/suexec.xml.fr b/docs/manual/suexec.xml.fr index 375c9f0ed5..b6e1e829e4 100644 --- a/docs/manual/suexec.xml.fr +++ b/docs/manual/suexec.xml.fr @@ -3,7 +3,7 @@ - + + + + - + + + + + diff --git a/docs/manual/vhosts/examples.xml.ja b/docs/manual/vhosts/examples.xml.ja index bc4d48ad13..12d26a429f 100644 --- a/docs/manual/vhosts/examples.xml.ja +++ b/docs/manual/vhosts/examples.xml.ja @@ -1,7 +1,7 @@ - + + + + + + + + diff --git a/docs/manual/vhosts/name-based.xml.ja b/docs/manual/vhosts/name-based.xml.ja index df4b1719cc..cfd057e48f 100644 --- a/docs/manual/vhosts/name-based.xml.ja +++ b/docs/manual/vhosts/name-based.xml.ja @@ -1,7 +1,7 @@ - + + +