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 @@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 Modules | Related 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.
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.
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 Modules | Related 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.000sIn 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 @@
The Apache HTTP server offers a range of caching features that
are designed to improve the performance of the server in various
ways. The HTTP protocol contains built in support for an in-line caching
- mechanism
+ mechanism
described by section 13 of RFC2616, and the
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 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.
Multiple variants of the content can be cached side by side,
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 1The 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
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:
- +Content-Length, but for our purposes we only care that
keepalive was possible from the application, not that keepalive actually
- 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.
- +| Related Modules | Related 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.
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:
- +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:
- +Content-Length, but for our purposes we only care that
keepalive was possible from the application, not that keepalive actually
- 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.
- +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.
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.
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 functionThe 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.
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.
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
-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.
-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.
-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
-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:
-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.
-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:
-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.
-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:
-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.
-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:
-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.
-Let's start off by making a very simple request handler +
Let's start off by making a very simple request handler that does the following:
-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 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:
r->connection (conn_rec*): A record containing information about the current connectionr->user (char*): If the URI requires authentication, this is set to the username providedr->useragent_ip (char*): The IP address of the client connecting to usr->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.
-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:
-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: 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): ap_set_content_type(r, "text/plain"); /* force a raw text output */@@ -453,18 +453,18 @@ the next, without informing other handlers.
-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:
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:
-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.
-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:
-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.
-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:-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.
-
-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:
-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.
-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:
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
+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).exampleEnabled: This is the name of our directive. More precisely, it is what the user must put in his/her
+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.example_set_enabled: This is a reference to a C function that parses the directive and sets the configuration
+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.RSRC_CONF: This tells the server where the directive is permitted. We'll go into details on this value in the
+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."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.)
-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:
/* 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:
- Inside
/var/www, all requests for http://example.com must go to http://www.example.com
- Inside
/var/www/sub, all requests for foobar must go to index.php?foobar=true
-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:
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:-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:
- Proposes a merge of the two configurations into a new configuration for
/var/www/subdir
-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.
@@ -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
-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:
-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 connectionr->user (char*): If the URI requires authentication, this is set to the username providedr->useragent_ip (char*): The IP address of the client connecting to usr->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.
-
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);
@@ -430,8 +430,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);
@@ -442,7 +442,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 */
@@ -456,18 +456,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:
@@ -491,10 +491,10 @@ static int example_handler(request_rec *r)
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;
@@ -503,10 +503,10 @@ static int example_handler(request_rec *r)
-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:
@@ -523,47 +523,47 @@ static void register_hooks(apr_pool_t *pool)
-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;
ap_args_to_table(r, &GET);
-ap_parse_form_data(r, NULL, &POST, -1, 8192);
+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:
-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.
@@ -589,8 +589,8 @@ would have to resort to a few more lines, as outlined in-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:
@@ -609,15 +609,15 @@ static int example_handler(request_rec *r) 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) { @@ -630,27 +630,27 @@ static int example_handler(request_rec *r) } /* 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 */ @@ -665,7 +665,7 @@ static int example_handler(request_rec *r) 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++) { @@ -688,20 +688,20 @@ static int example_handler(request_rec *r) 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; } @@ -709,7 +709,7 @@ static int example_handler(request_rec *r)-This version in its entirety can be found here: +This version in its entirety can be found here: mod_example_2.c.
@@ -718,19 +718,19 @@ This version in its entirety can be found here:-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.
-
-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:
-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.
-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:
-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:
-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.
-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:
@@ -847,10 +847,10 @@ module AP_MODULE_DECLARE_DATA example_module =
-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:
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
+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).exampleEnabled: This is the name of our directive. More precisely, it is what the user must put in his/her
+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.example_set_enabled: This is a reference to a C function that parses the directive and sets the configuration
+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.RSRC_CONF: This tells the server where the directive is permitted. We'll go into details on this value in the
+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."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.)
-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:
-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:
@@ -994,7 +994,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; @@ -1032,7 +1032,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"; @@ -1059,7 +1059,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:
-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.
-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:
-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:
/var/www, all requests for http://example.com must go to http://www.example.com/var/www/sub, all requests for foobar must go to index.php?foobar=true-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:
@@ -1121,17 +1121,17 @@ example_config *config = (example_config*)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:
-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:
@@ -1180,12 +1180,12 @@ AP_INIT_TAKE1("exampleEnabled", example_set_enabled, NULL, RSRC_CONF, "Enable or -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:
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:
@@ -1228,9 +1228,9 @@ module AP_MODULE_DECLARE_DATA example_module =-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:
-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:
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:
/var/www/subdir
-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:
-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:
-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:
@@ -1576,11 +1576,11 @@ void *merge_dir_conf(apr_pool_t *pool, void *BASE, void *ADD)-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.
check_config hookap_process_fnmatch_configs() function to process wildcardsap_configfile_t, ap_cfg_getline(),
- ap_cfg_getc() to return error codes, and add
- ap_pcfg_strerror() for retrieving an error description.ap_configfile_t, ap_cfg_getline(),
+ ap_cfg_getc() to return error codes, and add
+ ap_pcfg_strerror() for retrieving an error description.AllowOverrideList directive.
@@ -131,7 +131,7 @@
ap_default_type, ap_requires, all
+ ap_default_type, ap_requires, all
2.2 authnz APIap_get_server_name_for_url to support IPv6
@@ -159,11 +159,11 @@
CONN_STATE valuesap_escape_html updated;
+ ap_escape_html updated;
ap_unescape_all, ap_escape_path_segment_bufferEXEC_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.EOR bucket typeap_process_async_requestAP_AUTH_INTERNAL_PER_CONF and
+ AP_AUTH_INTERNAL_PER_CONF and
AP_AUTH_INTERNAL_PER_URIaccess_checker_ex hook to apply additional access control
+ access_checker_ex hook to apply additional access control
and/or bypass authentication.ap_hook_check_access_ex,
- ap_hook_check_access, ap_hook_check_authn,
- ap_hook_check_authz which accept
+ ap_hook_check_access_ex,
+ ap_hook_check_access, ap_hook_check_authn,
+ ap_hook_check_authz which accept
AP_AUTH_INTERNAL_PER_* flagsap_hook_access_checker,
- access_checker_ex, ap_hook_check_user_id,
+ ap_hook_access_checker,
+ access_checker_ex, ap_hook_check_user_id,
ap_hook_auth_checkerWhen possible, registering all access control hooks (including @@ -213,7 +213,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.
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.
set_scoreboard (locking uses the new ap_mutex API)mpm_query, timed_callback, and
+ mpm_query, timed_callback, and
get_namemonitor hook,
- ap_reclaim_child_processes,
+ ap_reclaim_child_processes,
ap_relieve_child_processesunixd_configconn_rec->remote_ip and
+ conn_rec->remote_ip and
conn_rec->remote_addrconn_rec->client_ip and
+ conn_rec->client_ip and
conn_rec->client_addr.check_config hookap_process_fnmatch_configs() function to process wildcardsap_configfile_t, ap_cfg_getline(),
- ap_cfg_getc() to return error codes, and add
- ap_pcfg_strerror() for retrieving an error description.ap_configfile_t, ap_cfg_getline(),
+ ap_cfg_getc() to return error codes, and add
+ ap_pcfg_strerror() for retrieving an error description.ap_default_type, ap_requires, all
+ ap_default_type, ap_requires, all
2.2 authnz APIap_get_server_name_for_url to support IPv6
@@ -156,11 +156,11 @@
CONN_STATE valuesap_escape_html updated;
+ ap_escape_html updated;
ap_unescape_all, ap_escape_path_segment_bufferEXEC_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.EOR bucket typeap_process_async_requestAP_AUTH_INTERNAL_PER_CONF and
+ AP_AUTH_INTERNAL_PER_CONF and
AP_AUTH_INTERNAL_PER_URIaccess_checker_ex hook to apply additional access control
+ access_checker_ex hook to apply additional access control
and/or bypass authentication.ap_hook_check_access_ex,
- ap_hook_check_access, ap_hook_check_authn,
- ap_hook_check_authz which accept
+ ap_hook_check_access_ex,
+ ap_hook_check_access, ap_hook_check_authn,
+ ap_hook_check_authz which accept
AP_AUTH_INTERNAL_PER_* flagsap_hook_access_checker,
- access_checker_ex, ap_hook_check_user_id,
+ ap_hook_access_checker,
+ access_checker_ex, ap_hook_check_user_id,
ap_hook_auth_checkerWhen 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.
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.
set_scoreboard (locking uses the new ap_mutex API)mpm_query, timed_callback, and
+ mpm_query, timed_callback, and
get_namemonitor hook,
- ap_reclaim_child_processes,
+ ap_reclaim_child_processes,
ap_relieve_child_processesunixd_configconn_rec->remote_ip and
+ conn_rec->remote_ip and
conn_rec->remote_addrconn_rec->client_ip and
+ conn_rec->client_ip and
conn_rec->client_addr.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) {
DirectoryIndex,
+ the server. Example consumers of this API are
+ DirectoryIndex,
mod_autoindex, and mod_include.
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.
<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
-
When the server looks up a path via an internal
+
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.
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.# 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>
# 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>
mod_session modules and corresponding configuration.
-
+
mod_proxySessionHeader
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.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.
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_TSdiff --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
-
When the server looks up a path via an internal
+
dbm:/path/to/datafile
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
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)
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:
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.
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.
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
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.
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 @@ ServerHelloThis 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
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
Generally, only a small subset of this information is configured for a
- particular log. Refer to the documentation for the
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
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.
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 @@ ServerHelloThis 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
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
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 @@mod_rewrite permet de modifier les requtes
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 @@
Ce document passe en revue certains dtails 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 @@La fonctionnalit suEXEC permet l'excution 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 @@ - + + +