www/apache
1
0
Fork 0
mirror of https://github.com/apache/httpd.git synced 2025-08-01 07:26:57 +03:00
Code Activity

Another pass at the normalisation of the HTML tags. Some

Browse Source 
corrections coming up.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@80130 13f79535-47bb-0310-9956-ffa450edef68
This commit is contained in:
Ken Coar
1998-02-05 20:05:18 +00:00
parent 3ff603fdf5
commit 80c32a1d5f
75 changed files with 486 additions and 486 deletions
Download Patch File Download Diff File Expand all files Collapse all files

44
docs/manual/developer/API.html
View File

@ -11,7 +11,7 @@
ALINK="#FF0000"
>
<!--#include virtual="header.html" -->
<h1 ALIGN="CENTER">Apache API notes</H1>
<H1 ALIGN="CENTER">Apache API notes</H1>
These are some notes on the Apache API and the data structures you
have to deal with, etc. They are not yet nearly complete, but
@ -57,12 +57,12 @@ coming up, and in what order:
</MENU>
</UL>
<h2><A name="basics">Basic concepts.</A></h2>
<H2><A name="basics">Basic concepts.</A></H2>
We begin with an overview of the basic concepts behind the
API, and how they are manifested in the code.
<h3><A name="HMR">Handlers, Modules, and Requests</A></h3>
<H3><A name="HMR">Handlers, Modules, and Requests</A></H3>
Apache breaks down request handling into a series of steps, more or
less the same way the Netscape server API does (although this API has
@ -116,7 +116,7 @@ The handlers themselves are functions of one argument (a
<CODE>request_rec</CODE> structure. vide infra), which returns an
integer, as above.<P>
<h3><A name="moduletour">A brief tour of a module</A></h3>
<H3><A name="moduletour">A brief tour of a module</A></H3>
At this point, we need to explain the structure of a module. Our
candidate will be one of the messier ones, the CGI module --- this
@ -215,14 +215,14 @@ module cgi_module = {
};
</PRE>
<h2><A name="handlers">How handlers work</A></h2>
<H2><A name="handlers">How handlers work</A></H2>
The sole argument to handlers is a <CODE>request_rec</CODE> structure.
This structure describes a particular request which has been made to
the server, on behalf of a client. In most cases, each connection to
the client generates only one <CODE>request_rec</CODE> structure.<P>
<h3><A name="req_tour">A brief tour of the <CODE>request_rec</CODE></A></h3>
<H3><A name="req_tour">A brief tour of the <CODE>request_rec</CODE></A></H3>
The <CODE>request_rec</CODE> contains pointers to a resource pool
which will be cleared when the server is finished handling the
@ -329,7 +329,7 @@ struct request_rec {
</PRE>
<h3><A name="req_orig">Where request_rec structures come from</A></h3>
<H3><A name="req_orig">Where request_rec structures come from</A></H3>
Most <CODE>request_rec</CODE> structures are built by reading an HTTP
request from a client, and filling in the fields. However, there are
@ -370,7 +370,7 @@ a few exceptions:
function <CODE>run_sub_request</CODE>).
</UL>
<h3><A name="req_return">Handling requests, declining, and returning error codes</A></h3>
<H3><A name="req_return">Handling requests, declining, and returning error codes</A></H3>
As discussed above, each handler, when invoked to handle a particular
<CODE>request_rec</CODE>, has to return an <CODE>int</CODE> to
@ -389,7 +389,7 @@ the module should put a <CODE>Location</CODE> in the request's
<CODE>headers_out</CODE>, to indicate where the client should be
redirected <EM>to</EM>. <P>
<h3><A name="resp_handlers">Special considerations for response handlers</A></h3>
<H3><A name="resp_handlers">Special considerations for response handlers</A></H3>
Handlers for most phases do their work by simply setting a few fields
in the <CODE>request_rec</CODE> structure (or, in the case of access
@ -463,7 +463,7 @@ internally redirected should always return <CODE>OK</CODE>. <P>
(Invoking <CODE>internal_redirect</CODE> from handlers which are
<EM>not</EM> response handlers will lead to serious confusion).
<h3><A name="auth_handlers">Special considerations for authentication handlers</A></h3>
<H3><A name="auth_handlers">Special considerations for authentication handlers</A></H3>
Stuff that should be discussed here in detail:
@ -481,7 +481,7 @@ Stuff that should be discussed here in detail:
to be sent back).
</UL>
<h3><A name="log_handlers">Special considerations for logging handlers</A></h3>
<H3><A name="log_handlers">Special considerations for logging handlers</A></H3>
When a request has internally redirected, there is the question of
what to log. Apache handles this by bundling the entire chain of
@ -493,7 +493,7 @@ initial request from the client; note that the bytes_sent field will
only be correct in the last request in the chain (the one for which a
response was actually sent).
<h2><A name="pools">Resource allocation and resource pools</A></h2>
<H2><A name="pools">Resource allocation and resource pools</A></H2>
One of the problems of writing and designing a server-pool server is
that of preventing leakage, that is, allocating resources (memory,
@ -544,7 +544,7 @@ We begin here by describing how memory is allocated to pools, and then
discuss how other resources are tracked by the resource pool
machinery.
<h3>Allocation of memory in pools</h3>
<H3>Allocation of memory in pools</H3>
Memory is allocated to pools by calling the function
<CODE>palloc</CODE>, which takes two arguments, one being a pointer to
@ -583,7 +583,7 @@ sub-pools below, and is used in the directory-indexing code, in order
to avoid excessive storage allocation when listing directories with
thousands of files).
<h3>Allocating initialized memory</h3>
<H3>Allocating initialized memory</H3>
There are functions which allocate initialized memory, and are
frequently useful. The function <CODE>pcalloc</CODE> has the same
@ -604,7 +604,7 @@ of the strings, as a unit; for instance:
returns a pointer to 8 bytes worth of memory, initialized to
<CODE>"foo/bar"</CODE>.
<h3><A name="pool-files">Tracking open files, etc.</A></h3>
<H3><A name="pool-files">Tracking open files, etc.</A></H3>
As indicated above, resource pools are also used to track other sorts
of resources besides memory. The most common are open files. The
@ -638,13 +638,13 @@ systems such as Linux, which react badly if the same
file will eventually be closed regardless, but you should consider it
in cases where your module is opening, or could open, a lot of files).
<h3>Other sorts of resources --- cleanup functions</h3>
<H3>Other sorts of resources --- cleanup functions</H3>
More text goes here. Describe the the cleanup primitives in terms of
which the file stuff is implemented; also, <CODE>spawn_process</CODE>.
<h3>Fine control --- creating and dealing with sub-pools, with a note
on sub-requests</h3>
<H3>Fine control --- creating and dealing with sub-pools, with a note
on sub-requests</H3>
On rare occasions, too-free use of <CODE>palloc()</CODE> and the
associated primitives may result in undesirably profligate resource
@ -686,7 +686,7 @@ cleared. It is only when you are allocating many, many sub-requests
for a single main request that you should seriously consider the
<CODE>destroy...</CODE> functions).
<h2><A name="config">Configuration, commands and the like</A></h2>
<H2><A name="config">Configuration, commands and the like</A></H2>
One of the design goals for this server was to maintain external
compatibility with the NCSA 1.3 server --- that is, to read the same
@ -735,7 +735,7 @@ for handling them. That is solved the same way it is solved wherever
else similar problems come up, by tying those structures to the
per-transaction resource pool. <P>
<h3><A name="per-dir">Per-directory configuration structures</A></h3>
<H3><A name="per-dir">Per-directory configuration structures</A></H3>
Let's look out how all of this plays out in <CODE>mod_mime.c</CODE>,
which defines the file typing handler which emulates the NCSA server's
@ -828,7 +828,7 @@ consists solely of the state of the <CODE>XBITHACK</CODE>), and for
those modules, you can just not declare one, and leave the
corresponding structure slot in the module itself <CODE>NULL</CODE>.<P>
<h3><A name="commands">Command handling</A></h3>
<H3><A name="commands">Command handling</A></H3>
Now that we have these structures, we need to be able to figure out
how to fill them. That involves processing the actual
@ -967,7 +967,7 @@ int find_ct(request_rec *r)
</PRE>
<h3><A name="servconf">Side notes --- per-server configuration, virtual servers, etc.</A></h3>
<H3><A name="servconf">Side notes --- per-server configuration, virtual servers, etc.</A></H3>
The basic ideas behind per-server module configuration are basically
the same as those for per-directory configuration; there is a creation