home *** CD-ROM | disk | FTP | other *** search
/ Chip 2004 November / CMCD1104.ISO / Software / Complet / Apache / apache_2.0.52-win32-x86-no_ssl.msi / Data.Cab / F277796_request.xml < prev    next >
Extensible Markup Language  |  2004-04-17  |  12KB  |  258 lines
  1. <?xml version="1.0" encoding="UTF-8" ?>
  2. <!DOCTYPE manualpage SYSTEM "../style/manualpage.dtd">
  3. <?xml-stylesheet type="text/xsl" href="../style/manual.en.xsl"?>
  4. <!-- $Revision: 1.1.2.7 $ -->
  5.  
  6. <!--
  7.  Copyright 2003-2004 The Apache Software Foundation
  8.  
  9.  Licensed under the Apache License, Version 2.0 (the "License");
  10.  you may not use this file except in compliance with the License.
  11.  You may obtain a copy of the License at
  12.  
  13.      http://www.apache.org/licenses/LICENSE-2.0
  14.  
  15.  Unless required by applicable law or agreed to in writing, software
  16.  distributed under the License is distributed on an "AS IS" BASIS,
  17.  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  18.  See the License for the specific language governing permissions and
  19.  limitations under the License.
  20. -->
  21.  
  22. <manualpage metafile="request.xml.meta">
  23. <parentdocument href="./">Developer Documentation</parentdocument>
  24.  
  25. <title>Request Processing in Apache 2.0</title>
  26.  
  27. <summary>
  28.     <note type="warning"><title>Warning</title>
  29.       <p>Warning - this is a first (fast) draft that needs further
  30.       revision!</p>
  31.     </note>
  32.  
  33.     <p>Several changes in Apache 2.0 affect the internal request
  34.     processing mechanics. Module authors need to be aware of these
  35.     changes so they may take advantage of the optimizations and
  36.     security enhancements.</p>
  37.  
  38.     <p>The first major change is to the subrequest and redirect
  39.     mechanisms. There were a number of different code paths in
  40.     Apache 1.3 to attempt to optimize subrequest or redirect
  41.     behavior. As patches were introduced to 2.0, these
  42.     optimizations (and the server behavior) were quickly broken due
  43.     to this duplication of code. All duplicate code has been folded
  44.     back into <code>ap_process_internal_request()</code> to prevent
  45.     the code from falling out of sync again.</p>
  46.  
  47.     <p>This means that much of the existing code was 'unoptimized'.
  48.     It is the Apache HTTP Project's first goal to create a robust
  49.     and correct implementation of the HTTP server RFC. Additional
  50.     goals include security, scalability and optimization. New
  51.     methods were sought to optimize the server (beyond the
  52.     performance of Apache 1.3) without introducing fragile or
  53.     insecure code.</p>
  54. </summary>
  55.  
  56. <section id="processing"><title>The Request Processing Cycle</title>
  57.     <p>All requests pass through <code>ap_process_request_internal()</code>
  58.     in <code>request.c</code>, including subrequests and redirects. If a module
  59.     doesn't pass generated requests through this code, the author is cautioned
  60.     that the module may be broken by future changes to request
  61.     processing.</p>
  62.  
  63.     <p>To streamline requests, the module author can take advantage
  64.     of the hooks offered to drop out of the request cycle early, or
  65.     to bypass core Apache hooks which are irrelevant (and costly in
  66.     terms of CPU.)</p>
  67. </section>
  68.  
  69. <section id="parsing"><title>The Request Parsing Phase</title>
  70.     <section id="unescape"><title>Unescapes the URL</title>
  71.       <p>The request's <code>parsed_uri</code> path is unescaped, once and only
  72.       once, at the beginning of internal request processing.</p>
  73.  
  74.       <p>This step is bypassed if the proxyreq flag is set, or the
  75.       <code>parsed_uri.path</code> element is unset. The module has no further
  76.       control of this one-time unescape operation, either failing to
  77.       unescape or multiply unescaping the URL leads to security
  78.       reprecussions.</p>
  79.     </section>
  80.  
  81.     <section id="strip"><title>Strips Parent and This Elements from the
  82.     URI</title>
  83.       <p>All <code>/../</code> and <code>/./</code> elements are
  84.       removed by <code>ap_getparents()</code>. This helps to ensure
  85.       the path is (nearly) absolute before the request processing
  86.       continues.</p>
  87.  
  88.       <p>This step cannot be bypassed.</p>
  89.     </section>
  90.  
  91.     <section id="inital-location-walk"><title>Initial URI Location Walk</title>
  92.       <p>Every request is subject to an
  93.       <code>ap_location_walk()</code> call. This ensures that
  94.       <directive type="section" module="core">Location</directive> sections
  95.       are consistently enforced for all requests. If the request is an internal
  96.       redirect or a sub-request, it may borrow some or all of the processing
  97.       from the previous or parent request's ap_location_walk, so this step
  98.       is generally very efficient after processing the main request.</p>
  99.     </section>
  100.  
  101.     <section id="translate_name"><title>translate_name</title>
  102.       <p>Modules can determine the file name, or alter the given URI
  103.       in this step. For example, <module>mod_vhost_alias</module> will
  104.       translate the URI's path into the configured virtual host,
  105.       <module>mod_alias</module> will translate the path to an alias path,
  106.       and if the request falls back on the core, the <directive module="core"
  107.       >DocumentRoot</directive> is prepended to the request resource.</p>
  108.  
  109.       <p>If all modules <code>DECLINE</code> this phase, an error 500 is
  110.       returned to the browser, and a "couldn't translate name" error is logged
  111.       automatically.</p>
  112.     </section>
  113.  
  114.     <section id="map_to_storage"><title>Hook: map_to_storage</title>
  115.       <p>After the file or correct URI was determined, the
  116.       appropriate per-dir configurations are merged together. For
  117.       example, <module>mod_proxy</module> compares and merges the appropriate
  118.       <directive module="mod_proxy" type="section">Proxy</directive> sections.
  119.       If the URI is nothing more than a local (non-proxy) <code>TRACE</code>
  120.       request, the core handles the request and returns <code>DONE</code>.
  121.       If no module answers this hook with <code>OK</code> or <code>DONE</code>,
  122.       the core will run the request filename against the <directive
  123.       module="core" type="section">Directory</directive> and <directive
  124.       module="core" type="section">Files</directive> sections. If the request
  125.       'filename' isn't an absolute, legal filename, a note is set for
  126.       later termination.</p>
  127.     </section>
  128.  
  129.     <section id="location-walk"><title>URI Location Walk</title>
  130.       <p>Every request is hardened by a second
  131.       <code>ap_location_walk()</code> call. This reassures that a
  132.       translated request is still subjected to the configured
  133.       <directive module="core" type="section">Location</directive> sections.
  134.       The request again borrows some or all of the processing from its previous
  135.       <code>location_walk</code> above, so this step is almost always very
  136.       efficient unless the translated URI mapped to a substantially different
  137.       path or Virtual Host.</p>
  138.     </section>
  139.  
  140.     <section id="header_parser"><title>Hook: header_parser</title>
  141.       <p>The main request then parses the client's headers. This
  142.       prepares the remaining request processing steps to better serve
  143.       the client's request.</p>
  144.     </section>
  145. </section>
  146.  
  147. <section id="security"><title>The Security Phase</title>
  148.     <p>Needs Documentation. Code is:</p>
  149.  
  150.     <example><pre>
  151. switch (ap_satisfies(r)) {
  152. case SATISFY_ALL:
  153. case SATISFY_NOSPEC:
  154.     if ((access_status = ap_run_access_checker(r)) != 0) {
  155.         return decl_die(access_status, "check access", r);
  156.     }
  157.  
  158.     if (ap_some_auth_required(r)) {
  159.         if (((access_status = ap_run_check_user_id(r)) != 0)
  160.             || !ap_auth_type(r)) {
  161.             return decl_die(access_status, ap_auth_type(r)
  162.                           ? "check user.  No user file?"
  163.                           : "perform authentication. AuthType not set!",
  164.                           r);
  165.         }
  166.  
  167.         if (((access_status = ap_run_auth_checker(r)) != 0)
  168.             || !ap_auth_type(r)) {
  169.             return decl_die(access_status, ap_auth_type(r)
  170.                           ? "check access.  No groups file?"
  171.                           : "perform authentication. AuthType not set!",
  172.                           r);
  173.         }
  174.     }
  175.     break;
  176.  
  177. case SATISFY_ANY:
  178.     if (((access_status = ap_run_access_checker(r)) != 0)) {
  179.         if (!ap_some_auth_required(r)) {
  180.             return decl_die(access_status, "check access", r);
  181.         }
  182.  
  183.         if (((access_status = ap_run_check_user_id(r)) != 0)
  184.             || !ap_auth_type(r)) {
  185.             return decl_die(access_status, ap_auth_type(r)
  186.                           ? "check user.  No user file?"
  187.                           : "perform authentication. AuthType not set!",
  188.                           r);
  189.         }
  190.  
  191.         if (((access_status = ap_run_auth_checker(r)) != 0)
  192.             || !ap_auth_type(r)) {
  193.             return decl_die(access_status, ap_auth_type(r)
  194.                           ? "check access.  No groups file?"
  195.                           : "perform authentication. AuthType not set!",
  196.                           r);
  197.         }
  198.     }
  199.     break;
  200. }</pre>
  201.     </example>
  202. </section>
  203.  
  204. <section id="preparation"><title>The Preparation Phase</title>
  205.     <section id="type_checker"><title>Hook: type_checker</title>
  206.       <p>The modules have an opportunity to test the URI or filename
  207.       against the target resource, and set mime information for the
  208.       request. Both <module>mod_mime</module> and
  209.       <module>mod_mime_magic</module> use this phase to compare the file
  210.       name or contents against the administrator's configuration and set the
  211.       content type, language, character set and request handler. Some modules
  212.       may set up their filters or other request handling parameters at this
  213.       time.</p>
  214.  
  215.       <p>If all modules <code>DECLINE</code> this phase, an error 500 is
  216.       returned to the browser, and a "couldn't find types" error is logged
  217.       automatically.</p>
  218.     </section>
  219.  
  220.     <section id="fixups"><title>Hook: fixups</title>
  221.       <p>Many modules are 'trounced' by some phase above. The fixups
  222.       phase is used by modules to 'reassert' their ownership or force
  223.       the request's fields to their appropriate values. It isn't
  224.       always the cleanest mechanism, but occasionally it's the only
  225.       option.</p>
  226.     </section>
  227. </section>
  228.  
  229. <section id="handler"><title>The Handler Phase</title>
  230.     <p>This phase is <strong>not</strong> part of the processing in
  231.     <code>ap_process_request_internal()</code>. Many
  232.     modules prepare one or more subrequests prior to creating any
  233.     content at all. After the core, or a module calls
  234.     <code>ap_process_request_internal()</code> it then calls
  235.     <code>ap_invoke_handler()</code> to generate the request.</p>
  236.  
  237.     <section id="insert_filter"><title>Hook: insert_filter</title>
  238.       <p>Modules that transform the content in some way can insert
  239.       their values and override existing filters, such that if the
  240.       user configured a more advanced filter out-of-order, then the
  241.       module can move its order as need be.  There is no result code,
  242.       so actions in this hook better be trusted to always succeed.</p>
  243.     </section>
  244.  
  245.     <section id="hook_handler"><title>Hook: handler</title>
  246.       <p>The module finally has a chance to serve the request in its
  247.       handler hook. Note that not every prepared request is sent to
  248.       the handler hook. Many modules, such as <module>mod_autoindex</module>,
  249.       will create subrequests for a given URI, and then never serve the
  250.       subrequest, but simply lists it for the user. Remember not to
  251.       put required teardown from the hooks above into this module,
  252.       but register pool cleanups against the request pool to free
  253.       resources as required.</p>
  254.     </section>
  255. </section>
  256. </manualpage>
  257.  
  258.