From: Daniel Gruno Date: Fri, 20 Jul 2012 13:27:12 +0000 (+0000) Subject: xforms X-Git-Tag: 2.2.23~104 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=cc26c652d5646c6d0bf62b910a709321bc966244;p=thirdparty%2Fapache%2Fhttpd.git xforms git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x@1363771 13f79535-47bb-0310-9956-ffa450edef68 --- diff --git a/docs/manual/developer/hooks.html.en b/docs/manual/developer/hooks.html.en index 13b597572b6..b252e4e30f2 100644 --- a/docs/manual/developer/hooks.html.en +++ b/docs/manual/developer/hooks.html.en @@ -112,8 +112,8 @@

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 tradition Apache - hook return meaning "I didn't do anything", but it can be + caller. Note that DECLINED is the traditional + hook return value meaning "I didn't do anything", but it can be whatever suits you.

Alternatively, all hooks can be run until an error occurs. @@ -165,7 +165,7 @@

Add a hook registering function

-

During initialisation, Apache will call each modules hook +

During initialisation, the server will call each modules hook registering function, which is included in the module structure:

@@ -200,9 +200,9 @@ order relative to each other, but, of course, all modules using APR_HOOK_FIRST will be run before APR_HOOK_MIDDLE which are before APR_HOOK_LAST. Modules that don't care - when they are run should use APR_HOOK_MIDDLE. (I spaced - these out so people could do stuff like APR_HOOK_FIRST-2 - to get in slightly earlier, but is this wise? - Ben)

+ 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.

Note that there are two more values, APR_HOOK_REALLY_FIRST and APR_HOOK_REALLY_LAST. These diff --git a/docs/manual/developer/request.html.en b/docs/manual/developer/request.html.en index a4011bad86e..1f03190df44 100644 --- a/docs/manual/developer/request.html.en +++ b/docs/manual/developer/request.html.en @@ -5,7 +5,7 @@ This file is generated from xml source: DO NOT EDIT XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX --> -Request Processing in Apache 2.0 - Apache HTTP Server +Request Processing in the Apache HTTP Server 2.x - Apache HTTP Server @@ -19,7 +19,7 @@

<-
-Apache > HTTP Server > Documentation > Version 2.2 > Developer Documentation

Request Processing in Apache 2.0

+Apache > HTTP Server > Documentation > Version 2.2 > Developer Documentation

Request Processing in the Apache HTTP Server 2.x

Available Languages:  en 

@@ -29,15 +29,15 @@ revision!

-

Several changes in Apache 2.0 affect the internal request +

Several changes in 2.0 and above affect the internal request processing mechanics. Module authors need to be aware of these changes so they may take advantage of the optimizations and security enhancements.

The first major change is to the subrequest and redirect mechanisms. There were a number of different code paths in - Apache 1.3 to attempt to optimize subrequest or redirect - behavior. As patches were introduced to 2.0, these + 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 back into ap_process_request_internal() to prevent @@ -48,7 +48,7 @@ and correct implementation of the HTTP server RFC. Additional goals include security, scalability and optimization. New methods were sought to optimize the server (beyond the - performance of Apache 1.3) without introducing fragile or + performance of 1.3) without introducing fragile or insecure code.

  • The Request Processing Cycle
    • @@ -68,7 +68,7 @@

    To streamline requests, the module author can take advantage of the hooks offered to drop out of the request cycle early, or - to bypass core Apache hooks which are irrelevant (and costly in + to bypass core hooks which are irrelevant (and costly in terms of CPU.)

top
@@ -81,7 +81,7 @@ parsed_uri.path element is unset. The module has no further control of this one-time unescape operation, either failing to unescape or multiply unescaping the URL leads to security - reprecussions.

+ repercussions.

Strips Parent and This Elements from the @@ -154,9 +154,9 @@ switch (ap_satisfies(r)) { case SATISFY_ALL: case SATISFY_NOSPEC: - if ((access_status = ap_run_access_checker(r)) != 0) { - return decl_die(access_status, "check access", r); - } + if ((access_status = ap_run_access_checker(r)) != 0) { + return decl_die(access_status, "check access", r); + } if (ap_some_auth_required(r)) { if (((access_status = ap_run_check_user_id(r)) != 0)