| <?xml version="1.0" encoding="UTF-8" ?> |
| <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd"> |
| <?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?> |
| <!-- $LastChangedRevision$ --> |
| |
| <!-- |
| Licensed to the Apache Software Foundation (ASF) under one or more |
| contributor license agreements. See the NOTICE file distributed with |
| this work for additional information regarding copyright ownership. |
| The ASF licenses this file to You under the Apache License, Version 2.0 |
| (the "License"); you may not use this file except in compliance with |
| the License. You may obtain a copy of the License at |
| |
| http://www.apache.org/licenses/LICENSE-2.0 |
| |
| Unless required by applicable law or agreed to in writing, software |
| distributed under the License is distributed on an "AS IS" BASIS, |
| WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
| See the License for the specific language governing permissions and |
| limitations under the License. |
| --> |
| |
| <manualpage metafile="hooks.xml.meta"> |
| <parentdocument href="./">Developer Documentation</parentdocument> |
| |
| <title>Hook Functions in the Apache HTTP Server 2.x</title> |
| |
| <summary> |
| <note type="warning"><title>Warning</title> |
| <p>This document is still in development and may be partially out of |
| date.</p> |
| </note> |
| |
| <p>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.</p> |
| </summary> |
| |
| <section id="corehooks"><title>Core Hooks</title> |
| <p>The httpd's core modules offer a predefinined list of hooks |
| used during the standard <a href="./request.html">request processing</a> |
| phase. Creating a new hook will expose a function that |
| implements it (see sections below) but it is essential to undestand that you will not |
| extend the httpd's core hooks. Their presence and order in the request processing is in fact |
| a consequence of how they are called in <code>server/request.c</code> |
| (check <a href="./modguide.html#hooking">this section</a> |
| for an overview). The core hooks are listed in the |
| <a href="https://ci.apache.org/projects/httpd/trunk/doxygen/group__hooks.html">doxygen documentation</a>.</p> |
| |
| <p>Reading <a href="./modguide.html">guide for developing modules</a> and |
| <a href="./request.html">request processing</a> before proceeding is |
| highly recomended. |
| </p> |
| </section> |
| |
| <section id="create"><title>Creating a hook function</title> |
| <p>In order to create a new hook, four things need to be |
| done:</p> |
| |
| <section id="create-declare"><title>Declare the hook function</title> |
| <p>Use the <code>AP_DECLARE_HOOK</code> macro, which needs to be given |
| the return type of the hook function, the name of the hook, and the |
| arguments. For example, if the hook returns an <code>int</code> and |
| takes a <code>request_rec *</code> and an <code>int</code> and is |
| called <code>do_something</code>, then declare it like this:</p> |
| <highlight language="c"> |
| AP_DECLARE_HOOK(int, do_something, (request_rec *r, int n)) |
| </highlight> |
| |
| <p>This should go in a header which modules will include if |
| they want to use the hook.</p> |
| </section> |
| |
| <section id="create-create"><title>Create the hook structure</title> |
| <p>Each source file that exports a hook has a private structure |
| which is used to record the module functions that use the hook. |
| This is declared as follows:</p> |
| |
| <highlight language="c"> |
| APR_HOOK_STRUCT( |
| APR_HOOK_LINK(do_something) |
| ... |
| ) |
| </highlight> |
| </section> |
| |
| <section id="create-implement"><title>Implement the hook caller</title> |
| <p>The source file that exports the hook has to implement a |
| function that will call the hook. There are currently three |
| possible ways to do this. In all cases, the calling function is |
| called <code>ap_run_<var>hookname</var>()</code>.</p> |
| |
| <section><title>Void hooks</title> |
| <p>If the return value of a hook is <code>void</code>, then all the |
| hooks are called, and the caller is implemented like this:</p> |
| |
| <highlight language="c"> |
| AP_IMPLEMENT_HOOK_VOID(do_something, (request_rec *r, int n), (r, n)) |
| </highlight> |
| |
| <p>The second and third arguments are the dummy argument |
| declaration and the dummy arguments as they will be used when |
| calling the hook. In other words, this macro expands to |
| something like this:</p> |
| |
| <highlight language="c"> |
| void ap_run_do_something(request_rec *r, int n) |
| { |
| ... |
| do_something(r, n); |
| } |
| </highlight> |
| </section> |
| |
| <section><title>Hooks that return a value</title> |
| <p>If the hook returns a value, then it can either be run until |
| the first hook that does something interesting, like so:</p> |
| |
| <highlight language="c"> |
| AP_IMPLEMENT_HOOK_RUN_FIRST(int, do_something, (request_rec *r, int n), (r, n), DECLINED) |
| </highlight> |
| |
| <p>The first hook that does <em>not</em> return <code>DECLINED</code> |
| stops the loop and its return value is returned from the hook |
| caller. Note that <code>DECLINED</code> is the traditional |
| hook return value meaning "I didn't do anything", but it can be |
| whatever suits you.</p> |
| |
| <p>Alternatively, all hooks can be run until an error occurs. |
| This boils down to permitting <em>two</em> return values, one of |
| which means "I did something, and it was OK" and the other |
| meaning "I did nothing". The first function that returns a |
| value other than one of those two stops the loop, and its |
| return is the return value. Declare these like so:</p> |
| |
| <highlight language="c"> |
| AP_IMPLEMENT_HOOK_RUN_ALL(int, do_something, (request_rec *r, int n), (r, n), OK, DECLINED) |
| </highlight> |
| |
| <p>Again, <code>OK</code> and <code>DECLINED</code> are the traditional |
| values. You can use what you want.</p> |
| </section> |
| </section> |
| |
| <section id="create-call"><title>Call the hook callers</title> |
| <p>At appropriate moments in the code, call the hook caller, |
| like so:</p> |
| |
| <highlight language="c"> |
| int n, ret; |
| request_rec *r; |
| |
| ret=ap_run_do_something(r, n); |
| </highlight> |
| </section> |
| </section> |
| |
| <section id="hooking"><title>Hooking the hook</title> |
| <p>A module that wants a hook to be called needs to do two |
| things.</p> |
| |
| <section id="hooking-implement"><title>Implement the hook function</title> |
| <p>Include the appropriate header, and define a static function |
| of the correct type:</p> |
| |
| <highlight language="c"> |
| static int my_something_doer(request_rec *r, int n) |
| { |
| ... |
| return OK; |
| } |
| </highlight> |
| </section> |
| |
| <section id="hooking-add"><title>Add a hook registering function</title> |
| <p>During initialisation, the server will call each modules hook |
| registering function, which is included in the module |
| structure:</p> |
| |
| <highlight language="c"> |
| static void my_register_hooks() |
| { |
| ap_hook_do_something(my_something_doer, NULL, NULL, APR_HOOK_MIDDLE); |
| } |
| |
| mode MODULE_VAR_EXPORT my_module = |
| { |
| ... |
| my_register_hooks /* register hooks */ |
| }; |
| </highlight> |
| </section> |
| |
| <section id="hooking-order"><title>Controlling hook calling order</title> |
| <p>In the example above, we didn't use the three arguments in |
| the hook registration function that control calling order of |
| all the functions registered within the hook. |
| There are two mechanisms for doing this. The first, rather |
| crude, method, allows us to specify roughly where the hook is |
| run relative to other modules. The final argument control this. |
| There are three possible values: <code>APR_HOOK_FIRST</code>, |
| <code>APR_HOOK_MIDDLE</code> and <code>APR_HOOK_LAST</code>.</p> |
| |
| <p>All modules using any particular value may be run in any |
| order relative to each other, but, of course, all modules using |
| <code>APR_HOOK_FIRST</code> will be run before <code>APR_HOOK_MIDDLE</code> |
| which are before <code>APR_HOOK_LAST</code>. Modules that don't care |
| when they are run should use <code>APR_HOOK_MIDDLE</code>. <em>These |
| values are spaced out, so that positions like <code>APR_HOOK_FIRST-2</code> |
| are possible to hook slightly earlier than other functions.</em></p> |
| |
| <p>Note that there are two more values, |
| <code>APR_HOOK_REALLY_FIRST</code> and <code>APR_HOOK_REALLY_LAST</code>. These |
| should only be used by the hook exporter.</p> |
| |
| <p>The other method allows finer control. When a module knows |
| that it must be run before (or after) some other modules, it |
| can specify them by name. The second (third) argument is a |
| NULL-terminated array of strings consisting of the names of |
| modules that must be run before (after) the current module. For |
| example, suppose we want "mod_xyz.c" and "mod_abc.c" to run |
| before we do, then we'd hook as follows:</p> |
| |
| <highlight language="c"> |
| static void register_hooks() |
| { |
| static const char * const aszPre[] = { "mod_xyz.c", "mod_abc.c", NULL }; |
| |
| ap_hook_do_something(my_something_doer, aszPre, NULL, APR_HOOK_MIDDLE); |
| } |
| </highlight> |
| |
| <p>Note that the sort used to achieve this is stable, so |
| ordering set by <code>APR_HOOK_<var>ORDER</var></code> is preserved, as far |
| as is possible.</p> |
| |
| </section> |
| </section> |
| </manualpage> |
| |