diff options
| author | Ken Coar <coar@apache.org> | 1998-05-20 16:22:48 +0200 |
|---|---|---|
| committer | Ken Coar <coar@apache.org> | 1998-05-20 16:22:48 +0200 |
| commit | 1b19735a79deebb3e7135d25b02fcf909541e386 (patch) | |
| tree | 47f18d5b8f0ac5500b0f4cf2306bd85d2b042fa2 | |
| parent | Some of my semi-regular HTML cleanup (tag ordering, B/I (diff) | |
| download | apache2-1b19735a79deebb3e7135d25b02fcf909541e386.tar.xz apache2-1b19735a79deebb3e7135d25b02fcf909541e386.zip | |
Part 2 of the semi-regular HTML normalisation. Now on to
apache-site... No thirty.
git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@81322 13f79535-47bb-0310-9956-ffa450edef68
46 files changed, 880 insertions, 667 deletions
diff --git a/docs/manual/bind.html b/docs/manual/bind.html index e3023bfe57..75bacbb253 100644 --- a/docs/manual/bind.html +++ b/docs/manual/bind.html @@ -29,18 +29,21 @@ There are two directives used to restrict or specify which addresses and ports Apache listens to. <UL> -<LI><A HREF="#bindaddress">BindAddress</A> is used to restrict the server to listening to +<LI><A HREF="#bindaddress">BindAddress</A> is used to restrict the server to + listening to a single address, and can be used to permit multiple Apache servers on the same machine listening to different IP addresses. -<LI><A HREF="#listen">Listen</A> can be used to make a single Apache server listen +<LI><A HREF="#listen">Listen</A> can be used to make a single Apache server + listen to more than one address and/or port. </UL> -<H3><A name="bindaddress">BindAddress</A></H3> +<H3><A NAME="bindaddress">BindAddress</A></H3> <A HREF="mod/directive-dict.html#Syntax" REL="Help" -><STRONG>Syntax:</STRONG></A> BindAddress <EM>[ * | IP-address | hostname ]</EM><BR> +><STRONG>Syntax:</STRONG></A> BindAddress <EM>[ * | IP-address + | hostname ]</EM><BR> <A HREF="mod/directive-dict.html#Default" REL="Help" @@ -59,7 +62,7 @@ is *, the server listens to all addresses. The port listened to is set with the <TT>Port</TT> directive. Only one BindAddress should be used. -<H3><A name="listen">Listen</A></H3> +<H3><A NAME="listen">Listen</A></H3> <A HREF="mod/directive-dict.html#Syntax" REL="Help" diff --git a/docs/manual/bind.html.en b/docs/manual/bind.html.en index e3023bfe57..75bacbb253 100644 --- a/docs/manual/bind.html.en +++ b/docs/manual/bind.html.en @@ -29,18 +29,21 @@ There are two directives used to restrict or specify which addresses and ports Apache listens to. <UL> -<LI><A HREF="#bindaddress">BindAddress</A> is used to restrict the server to listening to +<LI><A HREF="#bindaddress">BindAddress</A> is used to restrict the server to + listening to a single address, and can be used to permit multiple Apache servers on the same machine listening to different IP addresses. -<LI><A HREF="#listen">Listen</A> can be used to make a single Apache server listen +<LI><A HREF="#listen">Listen</A> can be used to make a single Apache server + listen to more than one address and/or port. </UL> -<H3><A name="bindaddress">BindAddress</A></H3> +<H3><A NAME="bindaddress">BindAddress</A></H3> <A HREF="mod/directive-dict.html#Syntax" REL="Help" -><STRONG>Syntax:</STRONG></A> BindAddress <EM>[ * | IP-address | hostname ]</EM><BR> +><STRONG>Syntax:</STRONG></A> BindAddress <EM>[ * | IP-address + | hostname ]</EM><BR> <A HREF="mod/directive-dict.html#Default" REL="Help" @@ -59,7 +62,7 @@ is *, the server listens to all addresses. The port listened to is set with the <TT>Port</TT> directive. Only one BindAddress should be used. -<H3><A name="listen">Listen</A></H3> +<H3><A NAME="listen">Listen</A></H3> <A HREF="mod/directive-dict.html#Syntax" REL="Help" diff --git a/docs/manual/cgi_path.html b/docs/manual/cgi_path.html index 569ddbb343..2b7bd963b1 100644 --- a/docs/manual/cgi_path.html +++ b/docs/manual/cgi_path.html @@ -16,7 +16,7 @@ <HR> -<H2><A name="over">Overview</A></H2> +<H2><A NAME="over">Overview</A></H2> <P>As implemented in Apache 1.1.1 and earlier versions, the method Apache used to create PATH_INFO in the CGI environment was @@ -27,7 +27,7 @@ applications, the Apache 1.2 behavior is still compatible with the CGI/1.1 specification, and CGI scripts can be easily modified (<A HREF="#compat">see below</A>). -<H2><A name="prob">The Problem</A></H2> +<H2><A NAME="prob">The Problem</A></H2> <P>Apache 1.1.1 and earlier implemented the PATH_INFO and SCRIPT_NAME environment variables by looking at the filename, not the URL. While @@ -46,7 +46,7 @@ SCRIPT_NAME to "<CODE>/cgi-</CODE>". Obviously, the latter is incorrect. In certain cases, this could even cause the server to crash.</P> -<H2><A name="solution">The Solution</A></H2> +<H2><A NAME="solution">The Solution</A></H2> <P>Apache 1.2 and later now determine SCRIPT_NAME and PATH_INFO by looking directly at the URL, and determining how much of the URL is @@ -67,7 +67,7 @@ sort of information is not a recommended method, and a script making use of it "deserves" not to work. Apache 1.2b3 and later, however, do provide <A HREF="#compat">a workaround.</A> -<H2><A name="compat">Compatibility with Previous Servers</A></H2> +<H2><A NAME="compat">Compatibility with Previous Servers</A></H2> <P>It may be necessary for a script that was designed for earlier versions of Apache or other servers to need the information that the diff --git a/docs/manual/cgi_path.html.en b/docs/manual/cgi_path.html.en index 569ddbb343..2b7bd963b1 100644 --- a/docs/manual/cgi_path.html.en +++ b/docs/manual/cgi_path.html.en @@ -16,7 +16,7 @@ <HR> -<H2><A name="over">Overview</A></H2> +<H2><A NAME="over">Overview</A></H2> <P>As implemented in Apache 1.1.1 and earlier versions, the method Apache used to create PATH_INFO in the CGI environment was @@ -27,7 +27,7 @@ applications, the Apache 1.2 behavior is still compatible with the CGI/1.1 specification, and CGI scripts can be easily modified (<A HREF="#compat">see below</A>). -<H2><A name="prob">The Problem</A></H2> +<H2><A NAME="prob">The Problem</A></H2> <P>Apache 1.1.1 and earlier implemented the PATH_INFO and SCRIPT_NAME environment variables by looking at the filename, not the URL. While @@ -46,7 +46,7 @@ SCRIPT_NAME to "<CODE>/cgi-</CODE>". Obviously, the latter is incorrect. In certain cases, this could even cause the server to crash.</P> -<H2><A name="solution">The Solution</A></H2> +<H2><A NAME="solution">The Solution</A></H2> <P>Apache 1.2 and later now determine SCRIPT_NAME and PATH_INFO by looking directly at the URL, and determining how much of the URL is @@ -67,7 +67,7 @@ sort of information is not a recommended method, and a script making use of it "deserves" not to work. Apache 1.2b3 and later, however, do provide <A HREF="#compat">a workaround.</A> -<H2><A name="compat">Compatibility with Previous Servers</A></H2> +<H2><A NAME="compat">Compatibility with Previous Servers</A></H2> <P>It may be necessary for a script that was designed for earlier versions of Apache or other servers to need the information that the diff --git a/docs/manual/content-negotiation.html b/docs/manual/content-negotiation.html index 98e0190677..3f9d60ecf2 100644 --- a/docs/manual/content-negotiation.html +++ b/docs/manual/content-negotiation.html @@ -294,7 +294,8 @@ remains, move onto the next test. <LI>Select the variants with the highest language quality factor <LI>Select the variants with the best language match, using either the - order of languages on the <CODE>LanguagePriority</CODE> directive (if present), + order of languages on the <CODE>LanguagePriority</CODE> directive (if + present), else the order of languages on the Accept-Language header. <LI>Select the variants with the highest 'level' media parameter @@ -330,7 +331,7 @@ and go to stage 3. </OL> -<H2><A name="better">Fiddling with Quality Values</A></H2> +<H2><A NAME="better">Fiddling with Quality Values</A></H2> <P> Apache sometimes changes the quality values from what would be @@ -435,10 +436,11 @@ Examples: </UL> <P> -Here some more examples of filenames together with valid and invalid hyperlinks: +Here some more examples of filenames together with valid and invalid +hyperlinks: </P> -<table border=1 cellpadding=8 cellspacing=0> +<TABLE BORDER=1 CELLPADDING=8 CELLSPACING=0> <TR> <TH>Filename</TH> <TH>Valid hyperlink</TH> diff --git a/docs/manual/content-negotiation.html.en b/docs/manual/content-negotiation.html.en index 98e0190677..3f9d60ecf2 100644 --- a/docs/manual/content-negotiation.html.en +++ b/docs/manual/content-negotiation.html.en @@ -294,7 +294,8 @@ remains, move onto the next test. <LI>Select the variants with the highest language quality factor <LI>Select the variants with the best language match, using either the - order of languages on the <CODE>LanguagePriority</CODE> directive (if present), + order of languages on the <CODE>LanguagePriority</CODE> directive (if + present), else the order of languages on the Accept-Language header. <LI>Select the variants with the highest 'level' media parameter @@ -330,7 +331,7 @@ and go to stage 3. </OL> -<H2><A name="better">Fiddling with Quality Values</A></H2> +<H2><A NAME="better">Fiddling with Quality Values</A></H2> <P> Apache sometimes changes the quality values from what would be @@ -435,10 +436,11 @@ Examples: </UL> <P> -Here some more examples of filenames together with valid and invalid hyperlinks: +Here some more examples of filenames together with valid and invalid +hyperlinks: </P> -<table border=1 cellpadding=8 cellspacing=0> +<TABLE BORDER=1 CELLPADDING=8 CELLSPACING=0> <TR> <TH>Filename</TH> <TH>Valid hyperlink</TH> diff --git a/docs/manual/custom-error.html b/docs/manual/custom-error.html index 5e2a3a9475..c76f224e26 100644 --- a/docs/manual/custom-error.html +++ b/docs/manual/custom-error.html @@ -49,7 +49,8 @@ </OL> <P>Redirecting to another URL can be useful, but only if some information - can be passed which can then be used to explain and/or log the error/problem + can be passed which can then be used to explain and/or log the + error/problem more clearly. <P>To achieve this, Apache will define new CGI-like environment @@ -70,18 +71,23 @@ REDIRECT_URL=/cgi-bin/buggy.pl <BR> <P>note the <CODE>REDIRECT_</CODE> prefix. - <P>At least <CODE>REDIRECT_URL</CODE> and <CODE>REDIRECT_QUERY_STRING</CODE> will - be passed to the new URL (assuming it's a cgi-script or a cgi-include). The - other variables will exist only if they existed prior to the error/problem. + <P>At least <CODE>REDIRECT_URL</CODE> and <CODE>REDIRECT_QUERY_STRING</CODE> + will + be passed to the new URL (assuming it's a cgi-script or a cgi-include). + The + other variables will exist only if they existed prior to the + error/problem. <STRONG>None</STRONG> of these will be set if your ErrorDocument is an - <EM>external</EM> redirect (i.e. anything starting with a protocol name + <EM>external</EM> redirect (<EM>i.e.</EM>, anything starting with a + scheme name like <CODE>http:</CODE>, even if it refers to the same host as the server).<P> <DT>Configuration <DD> Use of "ErrorDocument" is enabled for .htaccess files when the - <A HREF="mod/core.html#allowoverride">"FileInfo" override</A> is allowed. + <A HREF="mod/core.html#allowoverride">"FileInfo" override</A> is + allowed. <P>Here are some examples... @@ -126,7 +132,8 @@ ErrorDocument 401 /Subscription/how_to_subscribe.html <DT>Old behavior <DD>Standard CGI vars were made available to a script which has been - redirected to. No indication of where the redirection came from was provided. + redirected to. No indication of where the redirection came from was + provided. <P> @@ -146,6 +153,24 @@ Both the original URL and the URL being redirected to can be logged in the access log. </DL> +<P> +If the ErrorDocument specifies a local redirect to a CGI script, the script +should include a "<SAMP>Status:</SAMP>" header field in its output +in order to ensure the propagation all the way back to the client +of the error condition that caused it to be invoked. For instance, a Perl +ErrorDocument script might include the following: +</P> +<PRE> + : + print "Content-type: text/html\n"; + printf "Status: %s Condition Intercepted\n", $ENV{"REDIRECT_STATUS"}; + : +</PRE> +<P> +If the script is dedicated to handling a particular error condition, such as +<SAMP>404 Not Found</SAMP>, it can use the specific code and +error text instead. +</P> <!--#include virtual="footer.html" --> </BODY> diff --git a/docs/manual/custom-error.html.en b/docs/manual/custom-error.html.en index 5e2a3a9475..c76f224e26 100644 --- a/docs/manual/custom-error.html.en +++ b/docs/manual/custom-error.html.en @@ -49,7 +49,8 @@ </OL> <P>Redirecting to another URL can be useful, but only if some information - can be passed which can then be used to explain and/or log the error/problem + can be passed which can then be used to explain and/or log the + error/problem more clearly. <P>To achieve this, Apache will define new CGI-like environment @@ -70,18 +71,23 @@ REDIRECT_URL=/cgi-bin/buggy.pl <BR> <P>note the <CODE>REDIRECT_</CODE> prefix. - <P>At least <CODE>REDIRECT_URL</CODE> and <CODE>REDIRECT_QUERY_STRING</CODE> will - be passed to the new URL (assuming it's a cgi-script or a cgi-include). The - other variables will exist only if they existed prior to the error/problem. + <P>At least <CODE>REDIRECT_URL</CODE> and <CODE>REDIRECT_QUERY_STRING</CODE> + will + be passed to the new URL (assuming it's a cgi-script or a cgi-include). + The + other variables will exist only if they existed prior to the + error/problem. <STRONG>None</STRONG> of these will be set if your ErrorDocument is an - <EM>external</EM> redirect (i.e. anything starting with a protocol name + <EM>external</EM> redirect (<EM>i.e.</EM>, anything starting with a + scheme name like <CODE>http:</CODE>, even if it refers to the same host as the server).<P> <DT>Configuration <DD> Use of "ErrorDocument" is enabled for .htaccess files when the - <A HREF="mod/core.html#allowoverride">"FileInfo" override</A> is allowed. + <A HREF="mod/core.html#allowoverride">"FileInfo" override</A> is + allowed. <P>Here are some examples... @@ -126,7 +132,8 @@ ErrorDocument 401 /Subscription/how_to_subscribe.html <DT>Old behavior <DD>Standard CGI vars were made available to a script which has been - redirected to. No indication of where the redirection came from was provided. + redirected to. No indication of where the redirection came from was + provided. <P> @@ -146,6 +153,24 @@ Both the original URL and the URL being redirected to can be logged in the access log. </DL> +<P> +If the ErrorDocument specifies a local redirect to a CGI script, the script +should include a "<SAMP>Status:</SAMP>" header field in its output +in order to ensure the propagation all the way back to the client +of the error condition that caused it to be invoked. For instance, a Perl +ErrorDocument script might include the following: +</P> +<PRE> + : + print "Content-type: text/html\n"; + printf "Status: %s Condition Intercepted\n", $ENV{"REDIRECT_STATUS"}; + : +</PRE> +<P> +If the script is dedicated to handling a particular error condition, such as +<SAMP>404 Not Found</SAMP>, it can use the specific code and +error text instead. +</P> <!--#include virtual="footer.html" --> </BODY> diff --git a/docs/manual/developer/API.html b/docs/manual/developer/API.html index 3918922588..1b59833024 100644 --- a/docs/manual/developer/API.html +++ b/docs/manual/developer/API.html @@ -43,9 +43,11 @@ coming up, and in what order: <MENU> <LI> <A HREF="#req_tour">A brief tour of the <CODE>request_rec</CODE></A> <LI> <A HREF="#req_orig">Where request_rec structures come from</A> - <LI> <A HREF="#req_return">Handling requests, declining, and returning error codes</A> + <LI> <A HREF="#req_return">Handling requests, declining, and returning error + codes</A> <LI> <A HREF="#resp_handlers">Special considerations for response handlers</A> - <LI> <A HREF="#auth_handlers">Special considerations for authentication handlers</A> + <LI> <A HREF="#auth_handlers">Special considerations for authentication + handlers</A> <LI> <A HREF="#log_handlers">Special considerations for logging handlers</A> </MENU> <LI> <A HREF="#pools">Resource allocation and resource pools</A> @@ -53,16 +55,17 @@ coming up, and in what order: <MENU> <LI> <A HREF="#per-dir">Per-directory configuration structures</A> <LI> <A HREF="#commands">Command handling</A> - <LI> <A HREF="#servconf">Side notes --- per-server configuration, virtual servers, etc.</A> + <LI> <A HREF="#servconf">Side notes --- per-server configuration, + virtual servers, <EM>etc</EM>.</A> </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 +119,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 +218,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 +332,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 +373,8 @@ 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 +393,8 @@ 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 +468,8 @@ internally redirected should always return <CODE>OK</CODE>. <P> (Invoking <CODE>ap_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 +487,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 +499,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> <P> One of the problems of writing and designing a server-pool server is that of preventing leakage, that is, allocating resources (memory, @@ -610,7 +616,7 @@ of the strings, as a unit; for instance: returns a pointer to 8 bytes worth of memory, initialized to <CODE>"foo/bar"</CODE>. </P> -<H3><A name="pools-used">Commonly-used pools in the Apache Web server</A></H3> +<H3><A NAME="pools-used">Commonly-used pools in the Apache Web server</A></H3> <P> A pool is really defined by its lifetime more than anything else. There are some static pools in http_main which are passed to various @@ -633,7 +639,7 @@ non-http_main functions as arguments at opportune times. Here they are: </LI> <LI>created at the beginning of a config "cycle"; exists until the server is terminated or restarts; passed to all config-time - routines, either via cmd->pool, or as the "pool *p" argument on + routines, either via cmd->pool, or as the "pool *p" argument on those which don't take pools </LI> <LI>passed to the module init() functions @@ -652,8 +658,8 @@ non-http_main functions as arguments at opportune times. Here they are: <LI>subpool of permanent_pool </LI> <LI>created at the beginning of a config "cycle"; exists until the - end of config parsing; passed to config-time routines via - cmd->temp_pool. Somewhat of a "bastard child" because it isn't + end of config parsing; passed to config-time routines <EM>via</EM> + cmd->temp_pool. Somewhat of a "bastard child" because it isn't available everywhere. Used for temporary scratch space which may be needed by some config routines but which is deleted at the end of config. @@ -687,52 +693,54 @@ non-http_main functions as arguments at opportune times. Here they are: <LI>cleared by the child before going into the accept() loop to receive a connection </LI> - <LI>used as connection->pool + <LI>used as connection->pool </LI> </UL> </DD> - <DT>r->pool + <DT>r->pool </DT> <DD> <UL> - <LI>for the main request this is a subpool of connection->pool; for + <LI>for the main request this is a subpool of connection->pool; for subrequests it is a subpool of the parent request's pool. </LI> <LI>exists until the end of the request (<EM>i.e.</EM>, destroy_sub_req, or in child_main after process_request has finished) </LI> - <LI>note that r itself is allocated from r->pool; <EM>i.e.</EM>, r->pool is + <LI>note that r itself is allocated from r->pool; <EM>i.e.</EM>, + r->pool is first created and then r is the first thing palloc()d from it </LI> </UL> </DD> </DL> <P> -For almost everything folks do, r->pool is the pool to use. But you +For almost everything folks do, r->pool is the pool to use. But you can see how other lifetimes, such as pchild, are useful to some modules... such as modules that need to open a database connection once per child, and wish to clean it up when the child dies. </P> <P> You can also see how some bugs have manifested themself, such as setting -connection->user to a value from r->pool -- in this case connection exists -for the lifetime of ptrans, which is longer than r->pool (especially if -r->pool is a subrequest!). So the correct thing to do is to allocate -from connection->pool. +connection->user to a value from r->pool -- in this case +connection exists +for the lifetime of ptrans, which is longer than r->pool (especially if +r->pool is a subrequest!). So the correct thing to do is to allocate +from connection->pool. </P> <P> And there was another interesting bug in mod_include/mod_cgi. You'll see -in those that they do this test to decide if they should use r->pool -or r->main->pool. In this case the resource that they are registering -for cleanup is a child process. If it were registered in r->pool, +in those that they do this test to decide if they should use r->pool +or r->main->pool. In this case the resource that they are registering +for cleanup is a child process. If it were registered in r->pool, then the code would wait() for the child when the subrequest finishes. With mod_include this could be any old #include, and the delay can be up to 3 seconds... and happened quite frequently. Instead the subprocess -is registered in r->main->pool which causes it to be cleaned up when +is registered in r->main->pool which causes it to be cleaned up when the entire request is done -- <EM>i.e.</EM>, after the output has been sent to the client and logging has happened. </P> -<H3><A name="pool-files">Tracking open files, etc.</A></H3> +<H3><A NAME="pool-files">Tracking open files, etc.</A></H3> <P> As indicated above, resource pools are also used to track other sorts of resources besides memory. The most common are open files. The @@ -824,7 +832,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>ap_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 @@ -873,7 +881,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 @@ -966,7 +974,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 @@ -1105,7 +1113,8 @@ 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, <EM>etc</EM>.</A></H3> The basic ideas behind per-server module configuration are basically the same as those for per-directory configuration; there is a creation diff --git a/docs/manual/dns-caveats.html b/docs/manual/dns-caveats.html index 530573fc79..cbf8a57a9d 100644 --- a/docs/manual/dns-caveats.html +++ b/docs/manual/dns-caveats.html @@ -141,7 +141,7 @@ CGIs unless you use <A HREF="mod/mod_env.html"><CODE>mod_env</CODE></A> to control the environment. It's best to consult the man pages or FAQs for your OS. -<H3><A name="tips">Tips to Avoid these problems</A></H3> +<H3><A NAME="tips">Tips to Avoid these problems</A></H3> <UL> <LI> use IP addresses in <CODE><VirtualHost></CODE> diff --git a/docs/manual/ebcdic.html b/docs/manual/ebcdic.html index 72bdada6eb..8d97c989e3 100644 --- a/docs/manual/ebcdic.html +++ b/docs/manual/ebcdic.html @@ -45,7 +45,7 @@ decisions of the port to this machine. </P> - <H2 ALIGN=center>Design Goals</H2> + <H2 ALIGN=CENTER>Design Goals</H2> <P> One objective of the EBCDIC port was to maintain enough backwards compatibility with the (EBCDIC) CERN server to make the transition to @@ -61,7 +61,7 @@ documents which must be converted. </P> - <H2 ALIGN=center>Technical Solution</H2> + <H2 ALIGN=CENTER>Technical Solution</H2> <P> Since all Apache input and output is based upon the BUFF data type and its methods, the easiest solution was to add the conversion to @@ -87,7 +87,7 @@ </UL> </P> -<H2 ALIGN=center>Porting Notes</H2> +<H2 ALIGN=CENTER>Porting Notes</H2> <P> <OL> <LI> @@ -200,8 +200,8 @@ </OL> </P> - <H2 ALIGN=center>Document Storage Notes</H2> - <H3 ALIGN=center>Binary Files</H3> + <H2 ALIGN=CENTER>Document Storage Notes</H2> + <H3 ALIGN=CENTER>Binary Files</H3> <P> All files with a <SAMP>Content-Type:</SAMP> which does not start with <SAMP>text/</SAMP> are regarded as <EM>binary files</EM> @@ -217,7 +217,7 @@ (the -b switch is not supported in unix rcp's). </P> - <H3 ALIGN=center>Text Documents</H3> + <H3 ALIGN=CENTER>Text Documents</H3> <P> The default assumption of the server is that Text Files (i.e., all files whose <SAMP>Content-Type:</SAMP> starts with @@ -225,13 +225,13 @@ set of the host, EBCDIC. </P> - <H3 ALIGN=center>Server Side Included Documents</H3> + <H3 ALIGN=CENTER>Server Side Included Documents</H3> <P> SSI documents must currently be stored in EBCDIC only. No provision is made to convert it from ASCII before processing. </P> - <H2 ALIGN=center>Apache Modules' Status</H2> + <H2 ALIGN=CENTER>Apache Modules' Status</H2> <TABLE BORDER ALIGN=middle> <TR> <TH>Module @@ -240,223 +240,223 @@ </TR> <TR> - <TD ALIGN=left>http_core - <TD ALIGN=center>+ + <TD ALIGN=LEFT>http_core + <TD ALIGN=CENTER>+ <TD> </TR> <TR> - <TD ALIGN=left>mod_access - <TD ALIGN=center>+ + <TD ALIGN=LEFT>mod_access + <TD ALIGN=CENTER>+ <TD> </TR> <TR> - <TD ALIGN=left>mod_actions - <TD ALIGN=center>? + <TD ALIGN=LEFT>mod_actions + <TD ALIGN=CENTER>? <TD> </TR> <TR> - <TD ALIGN=left>mod_alias - <TD ALIGN=center>+ + <TD ALIGN=LEFT>mod_alias + <TD ALIGN=CENTER>+ <TD> </TR> <TR> - <TD ALIGN=left>mod_asis - <TD ALIGN=center>? + <TD ALIGN=LEFT>mod_asis + <TD ALIGN=CENTER>? <TD> </TR> <TR> - <TD ALIGN=left>mod_auth - <TD ALIGN=center>+ + <TD ALIGN=LEFT>mod_auth + <TD ALIGN=CENTER>+ <TD> </TR> <TR> - <TD ALIGN=left>mod_auth_anon - <TD ALIGN=center>+ + <TD ALIGN=LEFT>mod_auth_anon + <TD ALIGN=CENTER>+ <TD> </TR> <TR> - <TD ALIGN=left>mod_auth_db - <TD ALIGN=center>? + <TD ALIGN=LEFT>mod_auth_db + <TD ALIGN=CENTER>? <TD>with own libdb.a </TR> <TR> - <TD ALIGN=left>mod_auth_dbm - <TD ALIGN=center>? + <TD ALIGN=LEFT>mod_auth_dbm + <TD ALIGN=CENTER>? <TD>with own libdb.a </TR> <TR> - <TD ALIGN=left>mod_autoindex - <TD ALIGN=center>+ + <TD ALIGN=LEFT>mod_autoindex + <TD ALIGN=CENTER>+ <TD> </TR> <TR> - <TD ALIGN=left>mod_cern_meta - <TD ALIGN=center>? + <TD ALIGN=LEFT>mod_cern_meta + <TD ALIGN=CENTER>? <TD> </TR> <TR> - <TD ALIGN=left>mod_cgi - <TD ALIGN=center>+ + <TD ALIGN=LEFT>mod_cgi + <TD ALIGN=CENTER>+ <TD> </TR> <TR> - <TD ALIGN=left>mod_digest - <TD ALIGN=center>- + <TD ALIGN=LEFT>mod_digest + <TD ALIGN=CENTER>- <TD>MD5 not ported yet </TR> <TR> - <TD ALIGN=left>mod_dir - <TD ALIGN=center>+ + <TD ALIGN=LEFT>mod_dir + <TD ALIGN=CENTER>+ <TD> </TR> <TR> - <TD ALIGN=left>mod_dld - <TD ALIGN=center>- + <TD ALIGN=LEFT>mod_dld + <TD ALIGN=CENTER>- <TD>no shared libs </TR> <TR> - <TD ALIGN=left>mod_env - <TD ALIGN=center>+ + <TD ALIGN=LEFT>mod_env + <TD ALIGN=CENTER>+ <TD> </TR> <TR> - <TD ALIGN=left>mod_example - <TD ALIGN=center>- + <TD ALIGN=LEFT>mod_example + <TD ALIGN=CENTER>- <TD>not tried yet </TR> <TR> - <TD ALIGN=left>mod_expires - <TD ALIGN=center>+ + <TD ALIGN=LEFT>mod_expires + <TD ALIGN=CENTER>+ <TD> </TR> <TR> - <TD ALIGN=left>mod_headers - <TD ALIGN=center>+ + <TD ALIGN=LEFT>mod_headers + <TD ALIGN=CENTER>+ <TD> </TR> <TR> - <TD ALIGN=left>mod_imap - <TD ALIGN=center>+ + <TD ALIGN=LEFT>mod_imap + <TD ALIGN=CENTER>+ <TD> </TR> <TR> - <TD ALIGN=left>mod_include - <TD ALIGN=center>+ + <TD ALIGN=LEFT>mod_include + <TD ALIGN=CENTER>+ <TD> </TR> <TR> - <TD ALIGN=left>mod_info - <TD ALIGN=center>+ + <TD ALIGN=LEFT>mod_info + <TD ALIGN=CENTER>+ <TD> </TR> <TR> - <TD ALIGN=left>mod_log_agent - <TD ALIGN=center>+ + <TD ALIGN=LEFT>mod_log_agent + <TD ALIGN=CENTER>+ <TD> </TR> <TR> - <TD ALIGN=left>mod_log_config - <TD ALIGN=center>+ + <TD ALIGN=LEFT>mod_log_config + <TD ALIGN=CENTER>+ <TD> </TR> <TR> - <TD ALIGN=left>mod_log_referer - <TD ALIGN=center>+ + <TD ALIGN=LEFT>mod_log_referer + <TD ALIGN=CENTER>+ <TD> </TR> <TR> - <TD ALIGN=left>mod_mime - <TD ALIGN=center>+ + <TD ALIGN=LEFT>mod_mime + <TD ALIGN=CENTER>+ <TD> </TR> <TR> - <TD ALIGN=left>mod_mime_magic - <TD ALIGN=center>- + <TD ALIGN=LEFT>mod_mime_magic + <TD ALIGN=CENTER>- <TD>not tried yet </TR> <TR> - <TD ALIGN=left>mod_negotiation - <TD ALIGN=center>+ + <TD ALIGN=LEFT>mod_negotiation + <TD ALIGN=CENTER>+ <TD> </TR> <TR> - <TD ALIGN=left>mod_proxy - <TD ALIGN=center>+ + <TD ALIGN=LEFT>mod_proxy + <TD ALIGN=CENTER>+ <TD> </TR> <TR> - <TD ALIGN=left>mod_rewrite - <TD ALIGN=center>? + <TD ALIGN=LEFT>mod_rewrite + <TD ALIGN=CENTER>? <TD>untested </TR> <TR> - <TD ALIGN=left>mod_setenvif - <TD ALIGN=center>+ + <TD ALIGN=LEFT>mod_setenvif + <TD ALIGN=CENTER>+ <TD> </TR> <TR> - <TD ALIGN=left>mod_speling - <TD ALIGN=center>+ + <TD ALIGN=LEFT>mod_speling + <TD ALIGN=CENTER>+ <TD> </TR> <TR> - <TD ALIGN=left>mod_status - <TD ALIGN=center>+ + <TD ALIGN=LEFT>mod_status + <TD ALIGN=CENTER>+ <TD> </TR> <TR> - <TD ALIGN=left>mod_unique_id - <TD ALIGN=center>+ + <TD ALIGN=LEFT>mod_unique_id + <TD ALIGN=CENTER>+ <TD> </TR> <TR> - <TD ALIGN=left>mod_userdir - <TD ALIGN=center>+ + <TD ALIGN=LEFT>mod_userdir + <TD ALIGN=CENTER>+ <TD> </TR> <TR> - <TD ALIGN=left>mod_usertrack - <TD ALIGN=center>? + <TD ALIGN=LEFT>mod_usertrack + <TD ALIGN=CENTER>? <TD>untested </TR> </TABLE> - <H2 ALIGN=center>Third Party Modules' Status</H2> + <H2 ALIGN=CENTER>Third Party Modules' Status</H2> <TABLE BORDER ALIGN=middle> <TR> <TH>Module @@ -465,26 +465,28 @@ </TR> <TR> - <TD ALIGN=left><A HREF="http://java.apache.org/">mod_jserv</A> - <TD ALIGN=center>- + <TD ALIGN=LEFT><A HREF="http://java.apache.org/">mod_jserv</A> + <TD ALIGN=CENTER>- <TD>JAVA still being ported. </TR> <TR> - <TD ALIGN=left><A HREF="http://www.php.net/">mod_php</A> - <TD ALIGN=center>- + <TD ALIGN=LEFT><A HREF="http://www.php.net/">mod_php</A> + <TD ALIGN=CENTER>- <TD>not ported yet </TR> <TR> - <TD ALIGN=left><A HREF="http://hpwww.ec-lyon.fr/~vincent/apache/mod_put.html">mod_put</A> - <TD ALIGN=center>? + <TD ALIGN=LEFT + ><A HREF="http://hpwww.ec-lyon.fr/~vincent/apache/mod_put.html">mod_put</A> + <TD ALIGN=CENTER>? <TD>untested </TR> <TR> - <TD ALIGN=left><A HREF="ftp://hachiman.vidya.com/pub/apache/">mod_session</A> - <TD ALIGN=center>- + <TD ALIGN=LEFT + ><A HREF="ftp://hachiman.vidya.com/pub/apache/">mod_session</A> + <TD ALIGN=CENTER>- <TD>untested </TR> diff --git a/docs/manual/handler.html b/docs/manual/handler.html index 638d740f8e..84cd97c06b 100644 --- a/docs/manual/handler.html +++ b/docs/manual/handler.html @@ -69,16 +69,18 @@ handlers in the standard distribution are as follows:</P> <HR> -<H2><A name="addhandler">AddHandler</A></H2> +<H2><A NAME="addhandler">AddHandler</A></H2> <A HREF="mod/directive-dict.html#Syntax" REL="Help" -><STRONG>Syntax:</STRONG></A> <AddHandler <EM>handler-name extension</EM>><BR> +><STRONG>Syntax:</STRONG></A> <AddHandler <EM>handler-name + extension</EM>><BR> <A HREF="mod/directive-dict.html#Context" REL="Help" -><STRONG>Context:</STRONG></A> server config, virtual host, directory, .htaccess<BR> +><STRONG>Context:</STRONG></A> server config, virtual host, directory, + .htaccess<BR> <A HREF="mod/directive-dict.html#Status" REL="Help" @@ -101,7 +103,7 @@ program.</P> <HR> -<H2><A name="sethandler">SetHandler</A></H2> +<H2><A NAME="sethandler">SetHandler</A></H2> <A HREF="mod/directive-dict.html#Syntax" diff --git a/docs/manual/handler.html.en b/docs/manual/handler.html.en index 638d740f8e..84cd97c06b 100644 --- a/docs/manual/handler.html.en +++ b/docs/manual/handler.html.en @@ -69,16 +69,18 @@ handlers in the standard distribution are as follows:</P> <HR> -<H2><A name="addhandler">AddHandler</A></H2> +<H2><A NAME="addhandler">AddHandler</A></H2> <A HREF="mod/directive-dict.html#Syntax" REL="Help" -><STRONG>Syntax:</STRONG></A> <AddHandler <EM>handler-name extension</EM>><BR> +><STRONG>Syntax:</STRONG></A> <AddHandler <EM>handler-name + extension</EM>><BR> <A HREF="mod/directive-dict.html#Context" REL="Help" -><STRONG>Context:</STRONG></A> server config, virtual host, directory, .htaccess<BR> +><STRONG>Context:</STRONG></A> server config, virtual host, directory, + .htaccess<BR> <A HREF="mod/directive-dict.html#Status" REL="Help" @@ -101,7 +103,7 @@ program.</P> <HR> -<H2><A name="sethandler">SetHandler</A></H2> +<H2><A NAME="sethandler">SetHandler</A></H2> <A HREF="mod/directive-dict.html#Syntax" diff --git a/docs/manual/install.html b/docs/manual/install.html index 077c4ef7c2..ad532557e1 100644 --- a/docs/manual/install.html +++ b/docs/manual/install.html @@ -110,8 +110,9 @@ directory of the Apache distribution. Change into this directory. The modules we place in the Apache distribution are the ones we have tested and are used regularly by various members of the Apache development group. Additional modules contributed by members or third -parties with specific needs or functions are available at <A -HREF="http://www.apache.org/dist/contrib/modules/"><URL:http://www.apache.org/dist/contrib/modules/></A>. +parties with specific needs or functions are available at +<<A HREF="http://www.apache.org/dist/contrib/modules/" + >http://www.apache.org/dist/contrib/modules/</A>>. There are instructions on that page for linking these modules into the core Apache code. diff --git a/docs/manual/install.html.en b/docs/manual/install.html.en index 077c4ef7c2..ad532557e1 100644 --- a/docs/manual/install.html.en +++ b/docs/manual/install.html.en @@ -110,8 +110,9 @@ directory of the Apache distribution. Change into this directory. The modules we place in the Apache distribution are the ones we have tested and are used regularly by various members of the Apache development group. Additional modules contributed by members or third -parties with specific needs or functions are available at <A -HREF="http://www.apache.org/dist/contrib/modules/"><URL:http://www.apache.org/dist/contrib/modules/></A>. +parties with specific needs or functions are available at +<<A HREF="http://www.apache.org/dist/contrib/modules/" + >http://www.apache.org/dist/contrib/modules/</A>>. There are instructions on that page for linking these modules into the core Apache code. diff --git a/docs/manual/invoking.html b/docs/manual/invoking.html index e7767cbbdf..df0a4d0445 100644 --- a/docs/manual/invoking.html +++ b/docs/manual/invoking.html @@ -46,13 +46,14 @@ use this mode to provide ordinary web service. <DT><CODE>-v</CODE> <DD>Print the version of httpd and its build date, and then exit. -<DT><A name="version"><CODE>-V</CODE></A> +<DT><A NAME="version"><CODE>-V</CODE></A> <DD>Print the base version of httpd, its sub-version if defined, its build date, and a list of compile time settings which influence the -behavior and performance of the apache server (e.g., <SAMP>-D USE_MMAP_FILES</SAMP>), +behavior and performance of the apache server (<EM>e.g.</EM>, +<SAMP>-DUSE_MMAP_FILES</SAMP>), then exit. -<DT><A name="help"><CODE>-h</CODE></A> +<DT><A NAME="help"><CODE>-h</CODE></A> <DD>Give a list of directives together with expected arguments and places where the directive is valid. (New in Apache 1.2) @@ -93,7 +94,8 @@ The filename may be overridden with the However, these conventions need not be adhered to. <P> The server also reads a file containing mime document types; the filename -is set by the <A HREF="mod/mod_mime.html#typesconfig">TypesConfig</A> directive, +is set by the <A HREF="mod/mod_mime.html#typesconfig">TypesConfig</A> +directive, and is <CODE>conf/mime.types</CODE> by default. <H2>Log files</H2> @@ -119,15 +121,16 @@ kill the children httpd processes. <H3>Error log</H3> The server will log error messages to a log file, <CODE>logs/error_log</CODE> by default. The filename can be set using the -<A HREF="mod/core.html#errorlog">ErrorLog</A> directive; different error logs can +<A HREF="mod/core.html#errorlog">ErrorLog</A> directive; different error logs +can be set for different <A HREF="mod/core.html#virtualhost">virtual hosts</A>. <H3>Transfer log</H3> The server will typically log each request to a transfer file, <CODE>logs/access_log</CODE> by default. The filename can be set using a -<A HREF="mod/mod_log_config.html#transferlog">TransferLog</A> directive; different -transfer logs can be set for different <A HREF="mod/core.html#virtualhost">virtual -hosts</A>. +<A HREF="mod/mod_log_config.html#transferlog">TransferLog</A> directive; +different transfer logs can be set for different +<A HREF="mod/core.html#virtualhost">virtual hosts</A>. <!--#include virtual="footer.html" --> </BODY> diff --git a/docs/manual/invoking.html.en b/docs/manual/invoking.html.en index e7767cbbdf..df0a4d0445 100644 --- a/docs/manual/invoking.html.en +++ b/docs/manual/invoking.html.en @@ -46,13 +46,14 @@ use this mode to provide ordinary web service. <DT><CODE>-v</CODE> <DD>Print the version of httpd and its build date, and then exit. -<DT><A name="version"><CODE>-V</CODE></A> +<DT><A NAME="version"><CODE>-V</CODE></A> <DD>Print the base version of httpd, its sub-version if defined, its build date, and a list of compile time settings which influence the -behavior and performance of the apache server (e.g., <SAMP>-D USE_MMAP_FILES</SAMP>), +behavior and performance of the apache server (<EM>e.g.</EM>, +<SAMP>-DUSE_MMAP_FILES</SAMP>), then exit. -<DT><A name="help"><CODE>-h</CODE></A> +<DT><A NAME="help"><CODE>-h</CODE></A> <DD>Give a list of directives together with expected arguments and places where the directive is valid. (New in Apache 1.2) @@ -93,7 +94,8 @@ The filename may be overridden with the However, these conventions need not be adhered to. <P> The server also reads a file containing mime document types; the filename -is set by the <A HREF="mod/mod_mime.html#typesconfig">TypesConfig</A> directive, +is set by the <A HREF="mod/mod_mime.html#typesconfig">TypesConfig</A> +directive, and is <CODE>conf/mime.types</CODE> by default. <H2>Log files</H2> @@ -119,15 +121,16 @@ kill the children httpd processes. <H3>Error log</H3> The server will log error messages to a log file, <CODE>logs/error_log</CODE> by default. The filename can be set using the -<A HREF="mod/core.html#errorlog">ErrorLog</A> directive; different error logs can +<A HREF="mod/core.html#errorlog">ErrorLog</A> directive; different error logs +can be set for different <A HREF="mod/core.html#virtualhost">virtual hosts</A>. <H3>Transfer log</H3> The server will typically log each request to a transfer file, <CODE>logs/access_log</CODE> by default. The filename can be set using a -<A HREF="mod/mod_log_config.html#transferlog">TransferLog</A> directive; different -transfer logs can be set for different <A HREF="mod/core.html#virtualhost">virtual -hosts</A>. +<A HREF="mod/mod_log_config.html#transferlog">TransferLog</A> directive; +different transfer logs can be set for different +<A HREF="mod/core.html#virtualhost">virtual hosts</A>. <!--#include virtual="footer.html" --> </BODY> diff --git a/docs/manual/location.html b/docs/manual/location.html index 7cf602541c..2dddd2ee2c 100644 --- a/docs/manual/location.html +++ b/docs/manual/location.html @@ -15,7 +15,7 @@ <!--#include virtual="header.html" --> <H1 ALIGN="CENTER">Access Control by URL</H1> -<H2><A name="location">The <CODE><Location></CODE> Directive</A></H2> +<H2><A NAME="location">The <CODE><Location></CODE> Directive</A></H2> <A HREF="mod/directive-dict.html#Syntax" diff --git a/docs/manual/misc/API.html b/docs/manual/misc/API.html index 3918922588..1b59833024 100644 --- a/docs/manual/misc/API.html +++ b/docs/manual/misc/API.html @@ -43,9 +43,11 @@ coming up, and in what order: <MENU> <LI> <A HREF="#req_tour">A brief tour of the <CODE>request_rec</CODE></A> <LI> <A HREF="#req_orig">Where request_rec structures come from</A> - <LI> <A HREF="#req_return">Handling requests, declining, and returning error codes</A> + <LI> <A HREF="#req_return">Handling requests, declining, and returning error + codes</A> <LI> <A HREF="#resp_handlers">Special considerations for response handlers</A> - <LI> <A HREF="#auth_handlers">Special considerations for authentication handlers</A> + <LI> <A HREF="#auth_handlers">Special considerations for authentication + handlers</A> <LI> <A HREF="#log_handlers">Special considerations for logging handlers</A> </MENU> <LI> <A HREF="#pools">Resource allocation and resource pools</A> @@ -53,16 +55,17 @@ coming up, and in what order: <MENU> <LI> <A HREF="#per-dir">Per-directory configuration structures</A> <LI> <A HREF="#commands">Command handling</A> - <LI> <A HREF="#servconf">Side notes --- per-server configuration, virtual servers, etc.</A> + <LI> <A HREF="#servconf">Side notes --- per-server configuration, + virtual servers, <EM>etc</EM>.</A> </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 +119,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 +218,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 +332,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 +373,8 @@ 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 +393,8 @@ 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 +468,8 @@ internally redirected should always return <CODE>OK</CODE>. <P> (Invoking <CODE>ap_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 +487,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 +499,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> <P> One of the problems of writing and designing a server-pool server is that of preventing leakage, that is, allocating resources (memory, @@ -610,7 +616,7 @@ of the strings, as a unit; for instance: returns a pointer to 8 bytes worth of memory, initialized to <CODE>"foo/bar"</CODE>. </P> -<H3><A name="pools-used">Commonly-used pools in the Apache Web server</A></H3> +<H3><A NAME="pools-used">Commonly-used pools in the Apache Web server</A></H3> <P> A pool is really defined by its lifetime more than anything else. There are some static pools in http_main which are passed to various @@ -633,7 +639,7 @@ non-http_main functions as arguments at opportune times. Here they are: </LI> <LI>created at the beginning of a config "cycle"; exists until the server is terminated or restarts; passed to all config-time - routines, either via cmd->pool, or as the "pool *p" argument on + routines, either via cmd->pool, or as the "pool *p" argument on those which don't take pools </LI> <LI>passed to the module init() functions @@ -652,8 +658,8 @@ non-http_main functions as arguments at opportune times. Here they are: <LI>subpool of permanent_pool </LI> <LI>created at the beginning of a config "cycle"; exists until the - end of config parsing; passed to config-time routines via - cmd->temp_pool. Somewhat of a "bastard child" because it isn't + end of config parsing; passed to config-time routines <EM>via</EM> + cmd->temp_pool. Somewhat of a "bastard child" because it isn't available everywhere. Used for temporary scratch space which may be needed by some config routines but which is deleted at the end of config. @@ -687,52 +693,54 @@ non-http_main functions as arguments at opportune times. Here they are: <LI>cleared by the child before going into the accept() loop to receive a connection </LI> - <LI>used as connection->pool + <LI>used as connection->pool </LI> </UL> </DD> - <DT>r->pool + <DT>r->pool </DT> <DD> <UL> - <LI>for the main request this is a subpool of connection->pool; for + <LI>for the main request this is a subpool of connection->pool; for subrequests it is a subpool of the parent request's pool. </LI> <LI>exists until the end of the request (<EM>i.e.</EM>, destroy_sub_req, or in child_main after process_request has finished) </LI> - <LI>note that r itself is allocated from r->pool; <EM>i.e.</EM>, r->pool is + <LI>note that r itself is allocated from r->pool; <EM>i.e.</EM>, + r->pool is first created and then r is the first thing palloc()d from it </LI> </UL> </DD> </DL> <P> -For almost everything folks do, r->pool is the pool to use. But you +For almost everything folks do, r->pool is the pool to use. But you can see how other lifetimes, such as pchild, are useful to some modules... such as modules that need to open a database connection once per child, and wish to clean it up when the child dies. </P> <P> You can also see how some bugs have manifested themself, such as setting -connection->user to a value from r->pool -- in this case connection exists -for the lifetime of ptrans, which is longer than r->pool (especially if -r->pool is a subrequest!). So the correct thing to do is to allocate -from connection->pool. +connection->user to a value from r->pool -- in this case +connection exists +for the lifetime of ptrans, which is longer than r->pool (especially if +r->pool is a subrequest!). So the correct thing to do is to allocate +from connection->pool. </P> <P> And there was another interesting bug in mod_include/mod_cgi. You'll see -in those that they do this test to decide if they should use r->pool -or r->main->pool. In this case the resource that they are registering -for cleanup is a child process. If it were registered in r->pool, +in those that they do this test to decide if they should use r->pool +or r->main->pool. In this case the resource that they are registering +for cleanup is a child process. If it were registered in r->pool, then the code would wait() for the child when the subrequest finishes. With mod_include this could be any old #include, and the delay can be up to 3 seconds... and happened quite frequently. Instead the subprocess -is registered in r->main->pool which causes it to be cleaned up when +is registered in r->main->pool which causes it to be cleaned up when the entire request is done -- <EM>i.e.</EM>, after the output has been sent to the client and logging has happened. </P> -<H3><A name="pool-files">Tracking open files, etc.</A></H3> +<H3><A NAME="pool-files">Tracking open files, etc.</A></H3> <P> As indicated above, resource pools are also used to track other sorts of resources besides memory. The most common are open files. The @@ -824,7 +832,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>ap_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 @@ -873,7 +881,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 @@ -966,7 +974,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 @@ -1105,7 +1113,8 @@ 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, <EM>etc</EM>.</A></H3> The basic ideas behind per-server module configuration are basically the same as those for per-directory configuration; there is a creation diff --git a/docs/manual/misc/FAQ.html b/docs/manual/misc/FAQ.html index a1c5783c4e..949c18844a 100644 --- a/docs/manual/misc/FAQ.html +++ b/docs/manual/misc/FAQ.html @@ -3,8 +3,7 @@ <HEAD> <TITLE>Apache Server Frequently Asked Questions</TITLE> </HEAD> - - <!-- Background white, links blue (unvisited), navy (visited), red (active) --> +<!-- Background white, links blue (unvisited), navy (visited), red (active) --> <BODY BGCOLOR="#FFFFFF" TEXT="#000000" @@ -15,7 +14,7 @@ <!--#include virtual="header.html" --> <H1 ALIGN="CENTER">Apache Server Frequently Asked Questions</H1> <P> - $Revision: 1.115 $ ($Date: 1998/05/20 11:12:42 $) + $Revision: 1.116 $ ($Date: 1998/05/20 14:22:39 $) </P> <P> The latest version of this FAQ is always available from the main @@ -1122,7 +1121,7 @@ <HR> </LI> - <LI><A name="jdk1-and-http1.1"> + <LI><A NAME="jdk1-and-http1.1"> <STRONG>Why do my Java app[let]s give me plain text when I request an URL from an Apache server?</STRONG> </A> diff --git a/docs/manual/misc/client_block_api.html b/docs/manual/misc/client_block_api.html index c346c4adb3..e70a8284fc 100644 --- a/docs/manual/misc/client_block_api.html +++ b/docs/manual/misc/client_block_api.html @@ -65,7 +65,8 @@ accomplished while remaining backwards-compatible.</P> should proceed (to step 3). This step also sends a 100 Continue response to HTTP/1.1 clients, so should not be called until the module - is <STRONG>*definitely*</STRONG> ready to read content. (otherwise, the point of the + is <STRONG>*definitely*</STRONG> ready to read content. (otherwise, the + point of the 100 response is defeated). Never call this function more than once. <LI>Finally, call <CODE>ap_get_client_block</CODE> in a loop. Pass it a diff --git a/docs/manual/misc/custom_errordocs.html b/docs/manual/misc/custom_errordocs.html index 261f1b86be..7eee41a125 100644 --- a/docs/manual/misc/custom_errordocs.html +++ b/docs/manual/misc/custom_errordocs.html @@ -37,7 +37,8 @@ to return error messages generated by the server in the client's native language. </P> <P> -By using XSSI, all <A HREF="../mod/core.html#errordocument">customized messages</A> +By using XSSI, all +<A HREF="../mod/core.html#errordocument">customized messages</A> can share a homogenous and consistent style and layout, and maintenance work (changing images, changing links) is kept to a minimum because all layout information can be kept in a single file.<BR> @@ -90,7 +91,9 @@ of as much server support as we can get: <LI>By defining the <A HREF="../mod/core.html#options">MultiViews option</A>, we enable the language selection of the most appropriate language alternative (content negotiation). - <LI>By setting the <A HREF="../mod/mod_negotiation.html#languagepriority">LanguagePriority</A> + <LI>By setting the + <A HREF="../mod/mod_negotiation.html#languagepriority" + >LanguagePriority</A> directive we define a set of default fallback languages in the situation where the client's browser did not express any preference at all. <LI>By enabling <A HREF="../mod/mod_include.html">Server Side Includes</A> @@ -111,7 +114,8 @@ of as much server support as we can get: restricts these "special" settings to the error document directory and avoids an impact on any of the settings for the regular document tree. <LI>For each of the error codes to be handled (see RFC2068 for an exact - description of each error code, or look at <CODE>src/main/http_protocol.c</CODE> + description of each error code, or look at + <CODE>src/main/http_protocol.c</CODE> if you wish to see apache's standard messages), an <A HREF="../mod/core.html#errordocument">ErrorDocument</A> in the aliased <SAMP>/errordocs</SAMP> directory is defined. @@ -212,7 +216,8 @@ For simplicity, the header file is simply called <CODE>head.shtml</CODE> because it contains server-parsed content but no language specific information. The footer file exists once for each language translation, plus a symlink for the default language.<P> -<STRONG>Example:</STRONG> for english, french and german versions (default english)<BR> +<STRONG>Example:</STRONG> for English, French and German versions +(default english)<BR> <CODE>foot.shtml.en</CODE>,<BR> <CODE>foot.shtml.fr</CODE>,<BR> <CODE>foot.shtml.de</CODE>,<BR> @@ -228,15 +233,16 @@ See <A HREF="#listings">the listings below</A> to see an actual HTML implementation of the discussed example. -<H3><A NAME="createdocs">Creating ErrorDocuments in different languages</A></H3> +<H3><A NAME="createdocs">Creating ErrorDocuments in different languages</A> +</H3> After all this preparation work, little remains to be said about the actual documents. They all share a simple common structure: <PRE> -<!--#set var="title" value="<EM>error description title</EM>" --> -<!--#include virtual="head" --> +<!--#set var="title" value="<EM>error description title</EM>" --> +<!--#include virtual="head" --> <EM>explanatory error text</EM> -<!--#include virtual="foot" --> +<!--#include virtual="foot" --> </PRE> In the <A HREF="#listings">listings section</A>, you can see an example of a [400 Bad Request] error document. Documents as simple as that @@ -283,26 +289,26 @@ almost nothing but the error text (with conditional additions). Starting with this example, you will find it easy to add more error documents, or to translate the error documents to different languages. <HR><PRE> -<!--#set var="title" value="Bad Request" ---><!--#include virtual="head" --><P> +<!--#set var="title" value="Bad Request" +--><!--#include virtual="head" --><P> Your browser sent a request that this server could not understand: <BLOCKQUOTE> - <STRONG><!--#echo var="REQUEST_URI" --></STRONG> + <STRONG><!--#echo var="REQUEST_URI" --></STRONG> </BLOCKQUOTE> The request could not be understood by the server due to malformed syntax. The client should not repeat the request without modifications. </P> <P> - <!--#if expr="\"$HTTP_REFERER\" != \"\"" --> + <!--#if expr="\"$HTTP_REFERER\" != \"\"" --> Please inform the owner of - <A HREF="<!--#echo var="HTTP_REFERER" -->">the referring page</A> about + <A HREF="<!--#echo var="HTTP_REFERER" -->">the referring page</A> about the malformed link. <!--#else --> Please check your request for typing errors and retry. <!--#endif --> </P> -<!--#include virtual="foot" --> +<!--#include virtual="foot" --> </PRE><HR> Here is the complete <SAMP>head.shtml</SAMP> file (the funny line @@ -315,34 +321,34 @@ appears to support it (the latter requires server configuration lines of the form <BR><CODE>BrowserMatch "^Mozilla/[2-4]" anigif</CODE><BR> for browser types which support animated GIFs). <HR><PRE> -<!--#if expr="\"$SERVER_NAME\" = /.*\.mycompany\.com/" ---><!--#set var="IMG_CorpLogo" - value="http://$SERVER_NAME:$SERVER_PORT/errordocs/CorpLogo.gif" ---><!--#set var="ALT_CorpLogo" value="Powered by Linux!" +<!--#if expr="\"$SERVER_NAME\" = /.*\.mycompany\.com/" +--><!--#set var="IMG_CorpLogo" + value="http://$SERVER_NAME:$SERVER_PORT/errordocs/CorpLogo.gif" +--><!--#set var="ALT_CorpLogo" value="Powered by Linux!" --><!--#else ---><!--#set var="IMG_CorpLogo" - value="http://$SERVER_NAME:$SERVER_PORT/errordocs/PrivLogo.gif" ---><!--#set var="ALT_CorpLogo" value="Powered by Linux!" +--><!--#set var="IMG_CorpLogo" + value="http://$SERVER_NAME:$SERVER_PORT/errordocs/PrivLogo.gif" +--><!--#set var="ALT_CorpLogo" value="Powered by Linux!" --><!--#endif ---><!--#set var="IMG_BgImage" value="http://$SERVER_NAME:$SERVER_PORT/errordocs/BgImage.gif" ---><!--#set var="DOC_Apache" value="http://$SERVER_NAME:$SERVER_PORT/Apache/" ---><!--#if expr="$anigif" ---><!--#set var="IMG_Apache" value="http://$SERVER_NAME:$SERVER_PORT/icons/apache_anim.gif" +--><!--#set var="IMG_BgImage" value="http://$SERVER_NAME:$SERVER_PORT/errordocs/BgImage.gif" +--><!--#set var="DOC_Apache" value="http://$SERVER_NAME:$SERVER_PORT/Apache/" +--><!--#if expr="$anigif" +--><!--#set var="IMG_Apache" value="http://$SERVER_NAME:$SERVER_PORT/icons/apache_anim.gif" --><!--#else ---><!--#set var="IMG_Apache" value="http://$SERVER_NAME:$SERVER_PORT/icons/apache_pb.gif" +--><!--#set var="IMG_Apache" value="http://$SERVER_NAME:$SERVER_PORT/icons/apache_pb.gif" --><!--#endif ---><!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> +--><!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN"> <HTML> <HEAD> <TITLE> - [<!--#echo var="REDIRECT_STATUS" -->] <!--#echo var="title" --> + [<!--#echo var="REDIRECT_STATUS" -->] <!--#echo var="title" --> </TITLE> </HEAD> - <BODY BGCOLOR="white" BACKGROUND="<!--#echo var="IMG_BgImage" -->"><UL> - <H1 ALIGN="center"> - [<!--#echo var="REDIRECT_STATUS" -->] <!--#echo var="title" --> - <IMG SRC="<!--#echo var="IMG_CorpLogo" -->" - ALT="<!--#echo var="ALT_CorpLogo" -->" ALIGN=right> + <BODY BGCOLOR="white" BACKGROUND="<!--#echo var="IMG_BgImage" -->"><UL> + <H1 ALIGN="center"> + [<!--#echo var="REDIRECT_STATUS" -->] <!--#echo var="title" --> + <IMG SRC="<!--#echo var="IMG_CorpLogo" -->" + ALT="<!--#echo var="ALT_CorpLogo" -->" ALIGN=right> </H1> <HR><!-- ======================================================== --> <DIV> @@ -352,22 +358,22 @@ for browser types which support animated GIFs). </DIV> <HR> - <DIV ALIGN="right"><SMALL><SUP>Local Server time: - <!--#echo var="DATE_LOCAL" --> + <DIV ALIGN="right"><SMALL><SUP>Local Server time: + <!--#echo var="DATE_LOCAL" --> </SUP></SMALL></DIV> - <DIV ALIGN="center"> - <A HREF="<!--#echo var="DOC_Apache" -->"> - <IMG SRC="<!--#echo var="IMG_Apache" -->" BORDER=0 ALIGN="bottom" - ALT="Powered by <!--#echo var="SERVER_SOFTWARE" -->"></A><BR> - <SMALL><SUP><!--#set var="var" - value="Powered by $SERVER_SOFTWARE -- File last modified on $LAST_MODIFIED" - --><!--#echo var="var" --></SUP></SMALL> + <DIV ALIGN="center"> + <A HREF="<!--#echo var="DOC_Apache" -->"> + <IMG SRC="<!--#echo var="IMG_Apache" -->" BORDER=0 ALIGN="bottom" + ALT="Powered by <!--#echo var="SERVER_SOFTWARE" -->"></A><BR> + <SMALL><SUP><!--#set var="var" + value="Powered by $SERVER_SOFTWARE -- File last modified on $LAST_MODIFIED" + --><!--#echo var="var" --></SUP></SMALL> </DIV> <ADDRESS>If the indicated error looks like a misconfiguration, please inform - <A HREF="mailto:<!--#echo var="SERVER_ADMIN" -->" - SUBJECT="Feedback about Error message [<!--#echo var="REDIRECT_STATUS" - -->] <!--#echo var="title" -->, req=<!--#echo var="REQUEST_URI" -->"> - <!--#echo var="SERVER_NAME" -->'s WebMaster</A>. + <A HREF="mailto:<!--#echo var="SERVER_ADMIN" -->" + SUBJECT="Feedback about Error message [<!--#echo var="REDIRECT_STATUS" + -->] <!--#echo var="title" -->, req=<!--#echo var="REQUEST_URI" -->"> + <!--#echo var="SERVER_NAME" -->'s WebMaster</A>. </ADDRESS> </UL></BODY> </HTML> diff --git a/docs/manual/misc/fin_wait_2.html b/docs/manual/misc/fin_wait_2.html index 135b8b06e0..f264bf24a0 100644 --- a/docs/manual/misc/fin_wait_2.html +++ b/docs/manual/misc/fin_wait_2.html @@ -154,7 +154,8 @@ violation of the RFC, but it is widely recognized as being necessary. The following systems are known to have a timeout: <P> <UL> - <LI><A HREF="http://www.freebsd.org/">FreeBSD</A> versions starting at 2.0 or possibly earlier. + <LI><A HREF="http://www.freebsd.org/">FreeBSD</A> versions starting at + 2.0 or possibly earlier. <LI><A HREF="http://www.netbsd.org/">NetBSD</A> version 1.2(?) <LI><A HREF="http://www.openbsd.org/">OpenBSD</A> all versions(?) <LI><A HREF="http://www.bsdi.com/">BSD/OS</A> 2.1, with the @@ -204,8 +205,8 @@ The following systems are known to not have a timeout: </UL> <P> There is a -<A HREF="http://www.apache.org/dist/contrib/patches/1.2/fin_wait_2.patch"> -patch available</A> for adding a timeout to the FIN_WAIT_2 state; it +<A HREF="http://www.apache.org/dist/contrib/patches/1.2/fin_wait_2.patch" +>patch available</A> for adding a timeout to the FIN_WAIT_2 state; it was originally intended for BSD/OS, but should be adaptable to most systems using BSD networking code. You need kernel source code to be able to use it. If you do adapt it to work for any other systems, diff --git a/docs/manual/misc/howto.html b/docs/manual/misc/howto.html index 2eb207ad52..e2995c2473 100644 --- a/docs/manual/misc/howto.html +++ b/docs/manual/misc/howto.html @@ -1,7 +1,8 @@ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <HTML> <HEAD> -<META NAME="description" CONTENT="Some 'how to' tips for the Apache httpd server"> +<META NAME="description" + CONTENT="Some 'how to' tips for the Apache httpd server"> <META NAME="keywords" CONTENT="apache,redirect,robots,rotate,logfiles"> <TITLE>Apache HOWTO documentation</TITLE> </HEAD> @@ -19,13 +20,15 @@ How to: <UL> -<LI><A HREF="#redirect">redirect an entire server or directory to a single URL</A> +<LI><A HREF="#redirect">redirect an entire server or directory to a single + URL</A> <LI><A HREF="#logreset">reset your log files</A> <LI><A HREF="#stoprob">stop/restrict robots</A> </UL> <HR> -<H2><A name="redirect">How to redirect an entire server or directory to a single URL</A></H2> +<H2><A NAME="redirect">How to redirect an entire server or directory to a +single URL</A></H2> <P>There are two chief ways to redirect all requests for an entire server to a single location: one which requires the use of @@ -44,8 +47,9 @@ however, it may not be appropriate - for example, when the directory structure has changed after the move, and you simply want to direct people to the home page. -<P>The best option is to use the standard Apache module <CODE>mod_rewrite</CODE>. -If that module is compiled in, the following lines: +<P>The best option is to use the standard Apache module +<CODE>mod_rewrite</CODE>. +If that module is compiled in, the following lines <BLOCKQUOTE><PRE>RewriteEngine On RewriteRule /.* http://www.apache.org/ [R] @@ -56,10 +60,12 @@ what they gave in the original URL, they'll be sent to "http://www.apache.org". The second option is to set up a <CODE>ScriptAlias</CODE> pointing to -a <STRONG>cgi script</STRONG> which outputs a 301 or 302 status and the location +a <STRONG>cgi script</STRONG> which outputs a 301 or 302 status and the +location of the other server.</P> -<P>By using a <STRONG>cgi-script</STRONG> you can intercept various requests and +<P>By using a <STRONG>cgi-script</STRONG> you can intercept various requests +and treat them specially, e.g. you might want to intercept <STRONG>POST</STRONG> requests, so that the client isn't redirected to a script on the other server which expects POST information (a redirect will lose the POST @@ -68,7 +74,8 @@ want to compile mod_rewrite into your server. <P>Here's how to redirect all requests to a script... In the server configuration file, -<BLOCKQUOTE><PRE>ScriptAlias / /usr/local/httpd/cgi-bin/redirect_script</PRE></BLOCKQUOTE> +<BLOCKQUOTE><PRE>ScriptAlias / /usr/local/httpd/cgi-bin/redirect_script</PRE> +</BLOCKQUOTE> and here's a simple perl script to redirect requests: @@ -82,7 +89,7 @@ Location: http://www.some.where.else.com/\r\n\r\n"; <HR> -<H2><A name="logreset">How to reset your log files</A></H2> +<H2><A NAME="logreset">How to reset your log files</A></H2> <P>Sooner or later, you'll want to reset your log files (access_log and error_log) because they are too big, or full of old information you don't @@ -98,7 +105,8 @@ logfile moved. This results in a new logfile being created which is just as big as the old one, but it now contains thousands (or millions) of null characters.</P> -<P>The correct procedure is to move the logfile, then signal Apache to tell it to reopen the logfiles.</P> +<P>The correct procedure is to move the logfile, then signal Apache to tell +it to reopen the logfiles.</P> <P>Apache is signaled using the <STRONG>SIGHUP</STRONG> (-1) signal. e.g. <BLOCKQUOTE><CODE> @@ -107,7 +115,8 @@ kill -1 `cat httpd.pid` </CODE></BLOCKQUOTE> </P> -<P>Note: <CODE>httpd.pid</CODE> is a file containing the <STRONG>p</STRONG>rocess <STRONG>id</STRONG> +<P>Note: <CODE>httpd.pid</CODE> is a file containing the +<STRONG>p</STRONG>rocess <STRONG>id</STRONG> of the Apache httpd daemon, Apache saves this in the same directory as the log files.</P> @@ -115,7 +124,7 @@ files.</P> nightly or weekly basis.</P> <HR> -<H2><A name="stoprob">How to stop or restrict robots</A></H2> +<H2><A NAME="stoprob">How to stop or restrict robots</A></H2> <P>Ever wondered why so many clients are interested in a file called <CODE>robots.txt</CODE> which you don't have, and never did have?</P> @@ -147,7 +156,8 @@ stale by the time people find it in a search engine.</P> <P>If you decide to exclude robots completely, or just limit the areas in which they can roam, create a <CODE>robots.txt</CODE> file; refer -to the <A HREF="http://info.webcrawler.com/mak/projects/robots/robots.html">robot information pages</A> provided by Martijn Koster for the syntax.</P> +to the <A HREF="http://info.webcrawler.com/mak/projects/robots/robots.html" +>robot information pages</A> provided by Martijn Koster for the syntax.</P> <!--#include virtual="footer.html" --> </BODY> diff --git a/docs/manual/misc/known_client_problems.html b/docs/manual/misc/known_client_problems.html index 729d88abe7..63336e8a65 100644 --- a/docs/manual/misc/known_client_problems.html +++ b/docs/manual/misc/known_client_problems.html @@ -40,7 +40,7 @@ The admin typically controls which are set, and for which clients, by using <A HREF="../mod/mod_browser.html">mod_browser</A>. Unless otherwise noted all of these workarounds exist in versions 1.2 and later. -<H3><A name="trailing-crlf">Trailing CRLF on POSTs</A></H3> +<H3><A NAME="trailing-crlf">Trailing CRLF on POSTs</A></H3> <P>This is a legacy issue. The CERN webserver required <CODE>POST</CODE> data to have an extra <CODE>CRLF</CODE> following it. Thus many @@ -49,7 +49,7 @@ is not included in the <CODE>Content-Length</CODE> of the request. Apache works around this problem by eating any empty lines which appear before a request. -<H3><A name="broken-keepalive">Broken keepalive</A></H3> +<H3><A NAME="broken-keepalive">Broken keepalive</A></H3> <P>Various clients have had broken implementations of <EM>keepalive</EM> (persistent connections). In particular the Windows versions of @@ -66,13 +66,15 @@ strings just like Navigator. support keepalive when it is used on 301 or 302 (redirect) responses. Unfortunately Apache's <CODE>nokeepalive</CODE> code prior to 1.2.2 would not work with HTTP/1.1 clients. You must apply -<A HREF="http://www.apache.org/dist/patches/apply_to_1.2.1/msie_4_0b2_fixes.patch">this -patch</A> to version 1.2.1. Then add this to your config: +<A +HREF="http://www.apache.org/dist/patches/apply_to_1.2.1/msie_4_0b2_fixes.patch" +>this patch</A> to version 1.2.1. Then add this to your config: <BLOCKQUOTE><CODE> BrowserMatch "MSIE 4\.0b2;" nokeepalive </CODE></BLOCKQUOTE> -<H3><A name="force-response-1.0">Incorrect interpretation of <CODE>HTTP/1.1</CODE> in response</A></H3> +<H3><A NAME="force-response-1.0">Incorrect interpretation of +<CODE>HTTP/1.1</CODE> in response</A></H3> <P>To quote from section 3.1 of RFC1945: <BLOCKQUOTE> @@ -112,7 +114,8 @@ workaround is still: BrowserMatch "RealPlayer 4.0" force-response-1.0 </CODE></BLOCKQUOTE> -<H3><A name="msie4.0b2">Requests use HTTP/1.1 but responses must be in HTTP/1.0</A></H3> +<H3><A NAME="msie4.0b2">Requests use HTTP/1.1 but responses must be +in HTTP/1.0</A></H3> <P>MSIE 4.0b2 has this problem. Its Java VM makes requests in HTTP/1.1 format but the responses must be in HTTP/1.0 format (in particular, it @@ -122,10 +125,11 @@ is to fool Apache into believing the request came in HTTP/1.0 format. BrowserMatch "MSIE 4\.0b2;" downgrade-1.0 force-response-1.0 </CODE></BLOCKQUOTE> This workaround is available in 1.2.2, and in a -<A HREF="http://www.apache.org/dist/patches/apply_to_1.2.1/msie_4_0b2_fixes.patch">patch -</A> against 1.2.1. +<A +HREF="http://www.apache.org/dist/patches/apply_to_1.2.1/msie_4_0b2_fixes.patch" +>patch</A> against 1.2.1. -<H3><A name="257th-byte">Boundary problems with header parsing</A></H3> +<H3><A NAME="257th-byte">Boundary problems with header parsing</A></H3> <P>All versions of Navigator from 2.0 through 4.0b2 (and possibly later) have a problem if the trailing CRLF of the response header starts at @@ -135,7 +139,8 @@ on all responses. The workaround is to detect when this condition would occur in a response and add extra padding to the header to push the trailing CRLF past offset 258 of the response. -<H3><A name="boundary-string">Multipart responses and Quoted Boundary Strings</A></H3> +<H3><A NAME="boundary-string">Multipart responses and Quoted Boundary +Strings</A></H3> <P>On multipart responses some clients will not accept quotes (") around the boundary string. The MIME standard recommends that @@ -144,7 +149,7 @@ on one of the examples in RFC2068, which does not include quotes. Apache does not include quotes on its boundary strings to workaround this problem. -<H3><A name="byterange-requests">Byterange requests</A></H3> +<H3><A NAME="byterange-requests">Byterange requests</A></H3> <P>A byterange request is used when the client wishes to retrieve a portion of an object, not necessarily the entire object. There @@ -185,7 +190,8 @@ with MSIE 3 is actually due to the Acrobat plugin, not due to the browser. version 3.01 is used with it, it will not properly understand byteranges. The user must upgrade their Acrobat reader to 3.01. -<H3><A name="cookie-merge"><CODE>Set-Cookie</CODE> header is unmergeable</A></H3> +<H3><A NAME="cookie-merge"><CODE>Set-Cookie</CODE> header is +unmergeable</A></H3> <P>The HTTP specifications say that it is legal to merge headers with duplicate names into one (separated by semicolon). Some browsers @@ -194,7 +200,8 @@ that support Cookies don't like merged headers and prefer that each headers returned by a CGI, Apache will explicitly avoid merging any <CODE>Set-Cookie</CODE> headers. -<H3><A name="gif89-expires"><CODE>Expires</CODE> headers and GIF89A animations</A></H3> +<H3><A NAME="gif89-expires"><CODE>Expires</CODE> headers and GIF89A +animations</A></H3> <P>Navigator versions 2 through 4 will erroneously re-request GIF89A animations on each loop of the animation if the first @@ -205,7 +212,8 @@ HREF="http://www.arctic.org/~dgaudet/patches/apache-1.2-gif89-expires-hack.patch and for <A HREF="http://www.arctic.org/~dgaudet/patches/apache-1.3-gif89-expires-hack.patch">1.3</A>. -<H3><A name="no-content-length"><CODE>POST</CODE> without <CODE>Content-Length</CODE></A></H3> +<H3><A NAME="no-content-length"><CODE>POST</CODE> without +<CODE>Content-Length</CODE></A></H3> <P>In certain situations Navigator 3.01 through 3.03 appear to incorrectly issue a POST without the request body. There is no @@ -216,7 +224,7 @@ There's also <A HREF="http://www.arctic.org/~dgaudet/apache/no-content-length/"> some information</A> about the actual problem. -<H3><A name="jdk-12-bugs">JDK 1.2 betas lose parts of responses.</A></H3> +<H3><A NAME="jdk-12-bugs">JDK 1.2 betas lose parts of responses.</A></H3> <P>The http client in the JDK1.2beta2 and beta3 will throw away the first part of the response body when both the headers and the first part of the body are sent diff --git a/docs/manual/misc/perf-tuning.html b/docs/manual/misc/perf-tuning.html index c36636967a..4cc53a9ad9 100644 --- a/docs/manual/misc/perf-tuning.html +++ b/docs/manual/misc/perf-tuning.html @@ -1,9 +1,16 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"> <HTML> <HEAD> -<TITLE>Apache Performance Notes</TITLE> + <TITLE>Apache Performance Notes</TITLE> </HEAD> -<body bgcolor="#ffffff" text="#000000" link="#0000ff" vlink="#000080" alink="#ff0000"> - +<!-- Background white, links blue (unvisited), navy (visited), red (active) --> +<BODY + BGCOLOR="#FFFFFF" + TEXT="#000000" + LINK="#0000FF" + VLINK="#000080" + ALINK="#FF0000" +> <H1>Apache Performance Notes</H1> <P>Author: Dean Gaudet @@ -215,8 +222,8 @@ connection. The default <CODE>KeepAliveTimeout</CODE> of 15 seconds attempts to minimize this effect. The tradeoff here is between network bandwidth and server resources. In no event should you raise this above about 60 seconds, as -<A HREF="http://www.research.digital.com/wrl/techreports/abstracts/95.4.html"> -most of the benefits are lost</A>. +<A HREF="http://www.research.digital.com/wrl/techreports/abstracts/95.4.html" +>most of the benefits are lost</A>. <H3>Compile-Time Configuration Issues</H3> @@ -278,7 +285,8 @@ requests. All those blocked children will awaken and return from system and timing issues). They will all then fall down into the loop and try to <CODE>accept</CODE> the connection. But only one will succeed (assuming there's still only -one connection ready), the rest will be <EM>blocked</EM> in <CODE>accept</CODE>. +one connection ready), the rest will be <EM>blocked</EM> in +<CODE>accept</CODE>. This effectively locks those children into serving requests from that one socket and no other sockets, and they'll be stuck there until enough new requests appear on that socket to wake them all up. @@ -327,7 +335,7 @@ the inner loop. The loop looks like this (differences highlighted): } </PRE></BLOCKQUOTE> -<A name="serialize">The functions</A> +<A NAME="serialize">The functions</A> <CODE>accept_mutex_on</CODE> and <CODE>accept_mutex_off</CODE> implement a mutual exclusion semaphore. Only one child can have the mutex at any time. There are several choices for implementing these @@ -423,7 +431,9 @@ and then single-socket servers will not serialize at all. <H4>Lingering Close</H4> <P>As discussed in -<A HREF="ftp://ds.internic.net/internet-drafts/draft-ietf-http-connection-00.txt">draft-ietf-http-connection-00.txt</A> section 8, +<A + HREF="ftp://ds.internic.net/internet-drafts/draft-ietf-http-connection-00.txt" +>draft-ietf-http-connection-00.txt</A> section 8, in order for an HTTP server to <STRONG>reliably</STRONG> implement the protocol it needs to shutdown each direction of the communication independently (recall that a TCP connection is bi-directional, each half is independent @@ -648,7 +658,7 @@ properly implement the HTTP protocol. The second occurs because the Common Log Format dictates that the log record include a timestamp of the end of the request. A custom logging module could eliminate one of the calls. Or you can use a method which moves the time into shared memory, -see the <a href="#patches">patches section below</a>. +see the <A HREF="#patches">patches section below</A>. <P>As described earlier, <CODE>Rule STATUS=yes</CODE> causes two <CODE>gettimeofday</CODE> calls and a call to <CODE>times</CODE>: @@ -783,28 +793,28 @@ munmap(0x400e3000, 6144) = 0 That's 19 system calls, of which 4 remain relatively easy to remove, but don't seem worth the effort. -<h3><a name="patches">Appendix: Patches Available</a></h3> +<H3><A NAME="patches">Appendix: Patches Available</A></H3> There are -<a href="http://www.arctic.org/~dgaudet/apache/1.3/"> -several performance patches available for 1.3.</a> But they may +<A HREF="http://www.arctic.org/~dgaudet/apache/1.3/"> +several performance patches available for 1.3.</A> But they may be slightly out of date by the time Apache 1.3.0 has been released, it shouldn't be difficult for someone with a little C knowledge to update them. In particular: -<ul> -<li>A -<a href="http://www.arctic.org/~dgaudet/apache/1.3/shared_time.patch"> -patch</a> to remove all <code>time(2)</code> system calls. -<li>A -<a href="http://www.arctic.org/~dgaudet/apache/1.3/mod_include_speedups.patch"> -patch</a> to remove various system calls from <code>mod_include</code>, +<UL> +<LI>A +<A HREF="http://www.arctic.org/~dgaudet/apache/1.3/shared_time.patch" +>patch</A> to remove all <CODE>time(2)</CODE> system calls. +<LI>A +<A HREF="http://www.arctic.org/~dgaudet/apache/1.3/mod_include_speedups.patch" +>patch</A> to remove various system calls from <CODE>mod_include</CODE>, these calls are used by few sites but required for backwards compatibility. -<li>A -<a href="http://www.arctic.org/~dgaudet/apache/1.3/top_fuel.patch"> -patch</a> which integrates the above two plus a few other speedups at the +<LI>A +<A HREF="http://www.arctic.org/~dgaudet/apache/1.3/top_fuel.patch" +>patch</A> which integrates the above two plus a few other speedups at the cost of removing some functionality. -</ul> +</UL> <H3>Appendix: The Pre-Forking Model</H3> @@ -846,11 +856,11 @@ depending on the operating system. implementations of threaded Apache, one using the 1.3 code base on DCE, and one using a custom user-level threads package and the 1.0 code base, neither are available publically. There is also an experimental port of -Apache 1.3 to <a href="http://www.mozilla.org/docs/refList/refNSPR/"> -Netscape's Portable Run Time</a>, which -<a href="http://www.arctic.org/~dgaudet/apache/2.0/">is available</a> +Apache 1.3 to <A HREF="http://www.mozilla.org/docs/refList/refNSPR/"> +Netscape's Portable Run Time</A>, which +<A HREF="http://www.arctic.org/~dgaudet/apache/2.0/">is available</A> (but you're encouraged to join the -<a href="http://dev.apache.org/mailing-lists">new-httpd mailing list</a> +<A HREF="http://dev.apache.org/mailing-lists">new-httpd mailing list</A> if you intend to use it). Part of our redesign for version 2.0 of Apache will include abstractions of the server model so that we diff --git a/docs/manual/misc/security_tips.html b/docs/manual/misc/security_tips.html index 0ec79e5f71..aa6106bf73 100644 --- a/docs/manual/misc/security_tips.html +++ b/docs/manual/misc/security_tips.html @@ -22,7 +22,7 @@ the suggestions will be general, others specific to Apache. <HR> -<H2><A name="serverroot">Permissions on ServerRoot Directories</A></H2> +<H2><A NAME="serverroot">Permissions on ServerRoot Directories</A></H2> <P>In typical operation, Apache is started by the root user, and it switches to the user defined by the <A HREF="../mod/core.html#user"><STRONG>User</STRONG></A> directive to serve hits. @@ -81,7 +81,8 @@ directive.<P> <HR> <H2>Non Script Aliased CGI</H2> -<P>Allowing users to execute <STRONG>CGI</STRONG> scripts in any directory should only +<P>Allowing users to execute <STRONG>CGI</STRONG> scripts in any directory +should only be considered if; <OL> <LI>You trust your users not to write scripts which will deliberately or @@ -93,7 +94,8 @@ make one more potential hole irrelevant. <HR> <H2>Script Alias'ed CGI</H2> -<P>Limiting <STRONG>CGI</STRONG> to special directories gives the admin control over +<P>Limiting <STRONG>CGI</STRONG> to special directories gives the admin +control over what goes into those directories. This is inevitably more secure than non script aliased CGI, but <STRONG>only if users with write access to the directories are trusted</STRONG> or the admin is willing to test each new CGI diff --git a/docs/manual/platform/perf-bsd44.html b/docs/manual/platform/perf-bsd44.html index 96536c266e..a209c7736d 100644 --- a/docs/manual/platform/perf-bsd44.html +++ b/docs/manual/platform/perf-bsd44.html @@ -17,7 +17,8 @@ </A> <H1 ALIGN="CENTER">Running a High-Performance Web Server for BSD</H1> -Like other OS's, the listen queue is often the <STRONG>first limit hit</STRONG>. The +Like other OS's, the listen queue is often the <STRONG>first limit +hit</STRONG>. The following are comments from "Aaron Gifford <agifford@InfoWest.COM>" on how to fix this on BSDI 1.x, 2.x, and FreeBSD 2.0 (and earlier): @@ -167,7 +168,8 @@ value derived from maxusers proved sufficient for our load. <P> Be aware that your system may not boot with a kernel that is configured -to use more resources than you have available system RAM. <STRONG>ALWAYS</STRONG> +to use more resources than you have available system RAM. +<STRONG>ALWAYS</STRONG> have a known bootable kernel available when tuning your system this way, and use the system tools beforehand to learn if you need to buy more memory before tuning. @@ -187,8 +189,8 @@ Finally, there's the hard limit of child processes configured in Apache. <P> For versions of Apache later than 1.0.5 you'll need to change the -definition for <STRONG>HARD_SERVER_LIMIT</STRONG> in <EM>httpd.h</EM> and recompile -if you need to run more than the default 150 instances of httpd. +definition for <STRONG>HARD_SERVER_LIMIT</STRONG> in <EM>httpd.h</EM> and +recompile if you need to run more than the default 150 instances of httpd. <P> @@ -228,8 +230,8 @@ often maxed out.</BLOCKQUOTE> <H3>More welcome!</H3> -If you have tips to contribute, send mail to <A -HREF="mailto:brian@organic.com">brian@organic.com</A> +If you have tips to contribute, send mail to +<A HREF="mailto:brian@organic.com">brian@organic.com</A> <!--#include virtual="footer.html" --> </BODY></HTML> diff --git a/docs/manual/platform/perf-dec.html b/docs/manual/platform/perf-dec.html index 67eed58ff1..32245e0fbc 100644 --- a/docs/manual/platform/perf-dec.html +++ b/docs/manual/platform/perf-dec.html @@ -50,7 +50,7 @@ From mogul@pa.dec.com (Jeffrey Mogul) Organization DEC Western Research Date 30 May 1996 00:50:25 GMT Newsgroups <A HREF="news:comp.unix.osf.osf1">comp.unix.osf.osf1</A> -Message-ID <A HREF="news:4oirch$bc8@usenet.pa.dec.com"><4oirch$bc8@usenet.pa.dec.com></A> +Message-ID <4oirch$bc8@usenet.pa.dec.com> Subject Re: Web Site Performance References 1 @@ -63,8 +63,10 @@ In article <skoogDs54BH.9pF@netcom.com> skoog@netcom.com (Jim Skoog) write >runing DEC UNIX 3.2C, which run DEC's seal firewall and behind >that Alpha 1000 and 2100 webservers. -Our experience (running such Web servers as <A HREF="http://altavista.digital.com">altavista.digital.com</A> -and <A HREF="http://www.digital.com">www.digital.com</A>) is that there is one important kernel tuning +Our experience (running such Web servers as <A + HREF="http://altavista.digital.com">altavista.digital.com</A> +and <A HREF="http://www.digital.com" + >www.digital.com</A>) is that there is one important kernel tuning knob to adjust in order to get good performance on V3.2C. You need to patch the kernel global variable "somaxconn" (use dbx -k to do this) from its default value of 8 to something much larger. @@ -98,7 +100,8 @@ with no obvious performance bottlenecks at the millions-of-hits-per-day level. We have some Webstone performance results available at - <A HREF="http://www.digital.com/info/alphaserver/news/webff.html">http://www.digital.com/info/alphaserver/news/webff.html</A> + <A HREF="http://www.digital.com/info/alphaserver/news/webff.html" + >http://www.digital.com/info/alphaserver/news/webff.html</A> I'm not sure if these were done using V4.0 or an earlier version of Digital UNIX, although I suspect they were done using a test version of V4.0. @@ -113,7 +116,7 @@ From mogul@pa.dec.com (Jeffrey Mogul) Organization DEC Western Research Date 31 May 1996 21:01:01 GMT Newsgroups <A HREF="news:comp.unix.osf.osf1">comp.unix.osf.osf1</A> -Message-ID <A HREF="news:4onmmd$mmd@usenet.pa.dec.com"><4onmmd$mmd@usenet.pa.dec.com></A> +Message-ID <4onmmd$mmd@usenet.pa.dec.com> Subject Digital UNIX V3.2C Internet tuning patch info ---------------------------------------------------------------------------- @@ -136,7 +139,8 @@ so the description of the various tuning parameters in this README file might be useful to people running V4.0 systems. This patch kit does not appear to be available (yet?) from - <A HREF="http://www.service.digital.com/html/patch_service.html">http://www.service.digital.com/html/patch_service.html</A> + <A HREF="http://www.service.digital.com/html/patch_service.html" + >http://www.service.digital.com/html/patch_service.html</A> so I guess you'll have to call Digital's Customer Support to get it. -Jeff @@ -251,7 +255,7 @@ TUNING V3.2C Feature V3.2C patch V4.0 - ======= ===== ===== ==== +======= ===== ===== ==== somaxconn X X X sominconn - X X sobacklog_hiwat - X - diff --git a/docs/manual/platform/unixware.html b/docs/manual/platform/unixware.html index 458104a9d0..a77a3b5cd4 100644 --- a/docs/manual/platform/unixware.html +++ b/docs/manual/platform/unixware.html @@ -46,7 +46,8 @@ in order for Apache to work correctly on UnixWare 2.1.x. See <A HREF="http://www.sco.com">http://www.sco.com</A> for UnixWare patch information.<P> -<STRONG>NOTE:</STRONG> Unixware 2.1.2 and later already have patch ptf3123 included<P> +<STRONG>NOTE:</STRONG> Unixware 2.1.2 and later already have patch ptf3123 +included<P> In addition, make sure that USE_FCNTL_SERIALIZE_ACCEPT is defined (if not defined by Apache autoconfiguration). To reduce instances of connections diff --git a/docs/manual/platform/windows.html b/docs/manual/platform/windows.html index 9da3075dfa..a1499d8ff3 100644 --- a/docs/manual/platform/windows.html +++ b/docs/manual/platform/windows.html @@ -52,7 +52,7 @@ to help with development, or to track down bugs), see the section on <HR> -<H2><A name="req">Requirements</A></H2> +<H2><A NAME="req">Requirements</A></H2> <P>Apache 1.3b6 requires the following:</P> @@ -62,14 +62,14 @@ to help with development, or to track down bugs), see the section on requirements unknown) with a connection to a TCP/IP network. </UL> -<P><SMALL><A name="351">*</A> Apache may run with Windows NT 3.5.1, but +<P><SMALL><A NAME="351">*</A> Apache may run with Windows NT 3.5.1, but has not been tested.</SMALL></P> <P>If running on Windows 95, using the "Winsock2" upgrade is recommended but may not be necessary. If running on NT 4.0, installing Service Pack 2 is recommended.</P> -<H2><A name="down">Downloading Apache for Windows</A></H2> +<H2><A NAME="down">Downloading Apache for Windows</A></H2> <P>Information on the latest version of Apache can be found on the Apache web server at <A @@ -84,7 +84,7 @@ You should download the version of Apache for Windows with the ready to install and run. There may also be a <CODE>.zip</CODE> file containing the source code, to compile Apache yourself. -<H2><A name="inst">Installing Apache for Windows</A></H2> +<H2><A NAME="inst">Installing Apache for Windows</A></H2> Run the Apache <SAMP>.exe</SAMP> file you downloaded above. This will ask for: @@ -124,7 +124,7 @@ subdirectory <SAMP>htdocs</SAMP>. There are lots of other options which should be set before you start really using Apache. However to get started the files should work as installed. -<H2><A name="inst">Running Apache for Windows</A></H2> +<H2><A NAME="inst">Running Apache for Windows</A></H2> There are two ways you can run Apache: @@ -178,7 +178,7 @@ manual. If nothing happens or you get an error, look in the Once your basic installation is working, you should configure it properly by editing the files in the <SAMP>conf</SAMP> directory. -<H2><A name="use">Configuring Apache for Windows</A></H2> +<H2><A NAME="use">Configuring Apache for Windows</A></H2> Apache is configured by files in the <SAMP>conf</SAMP> directory. These are the same as files used to configure the Unix @@ -237,7 +237,7 @@ The main differences in Apache for Windows are: is available.</A> </UL> -<H2><A name="cmdline">Running Apache for Windows from the Command Line</A></H2> +<H2><A NAME="cmdline">Running Apache for Windows from the Command Line</A></H2> The Start menu icons and the NT Service manager can provide an simple interafce for administering Apache. But in some cases it is easier to @@ -301,7 +301,7 @@ listed above. Again note that once Apache has read the given on the <SAMP>ServerRoot</SAMP> directive line instead of the -f or -d command line argument. -<H2><A name="comp">Compiling Apache for Windows</A></H2> +<H2><A NAME="comp">Compiling Apache for Windows</A></H2> <P>Compiling Apache requires Microsoft Visual C++ 5.0 to be properly installed. It is easiest to compile with the command-line tools @@ -344,8 +344,10 @@ or -d command line argument. <P>To install the files into the <CODE>\Apache</CODE> directory automatically, use one the following nmake commands (see above):</P> <UL> -<LI><CODE>nmake /f Makefile.nt installr INSTDIR=<i>dir</i></CODE> (for release build) -<LI><CODE>nmake /f Makefile.nt installd INSTDIR=<i>dir</i></CODE> (for debug build) +<LI><CODE>nmake /f Makefile.nt installr INSTDIR=<EM>dir</EM></CODE> + (for release build) +<LI><CODE>nmake /f Makefile.nt installd INSTDIR=<EM>dir</EM></CODE> + (for debug build) </UL> The dir argument to INSTDIR gives the installation directory. The can @@ -354,12 +356,12 @@ be omitted if Apache is to be installed into <SAMP>\Apache</SAMP>. <P>This will install the following:</P> <UL> - <LI><CODE><i>dir</i>\Apache.exe</CODE> - Apache executable - <LI><CODE><i>dir</i>\ApacheCore.dll</CODE> - Main Apache shared library - <LI><CODE><i>dir</i>\modules\ApacheModule*.dll</CODE> - Optional Apache + <LI><CODE><EM>dir</EM>\Apache.exe</CODE> - Apache executable + <LI><CODE><EM>dir</EM>\ApacheCore.dll</CODE> - Main Apache shared library + <LI><CODE><EM>dir</EM>\modules\ApacheModule*.dll</CODE> - Optional Apache modules (7 files) - <LI><CODE><i>dir</i>\conf</CODE> - Empty configuration directory - <LI><CODE><i>dir</i>\logs</CODE> - Empty logging directory + <LI><CODE><EM>dir</EM>\conf</CODE> - Empty configuration directory + <LI><CODE><EM>dir</EM>\logs</CODE> - Empty logging directory </UL> <P>If you do not have nmake, or wish to install in a different directory, diff --git a/docs/manual/sections.html b/docs/manual/sections.html index b9a5679100..a8e4756d92 100644 --- a/docs/manual/sections.html +++ b/docs/manual/sections.html @@ -57,10 +57,12 @@ The order of merging is: </LI> - <LI><CODE><Files></CODE> and <CODE><FilesMatch></CODE> done simultaneously + <LI><CODE><Files></CODE> and <CODE><FilesMatch></CODE> done + simultaneously </LI> - <LI><CODE><Location></CODE> and <CODE><LocationMatch></CODE> done simultaneously + <LI><CODE><Location></CODE> and <CODE><LocationMatch></CODE> done + simultaneously </LI> </OL> diff --git a/docs/manual/sections.html.en b/docs/manual/sections.html.en index b9a5679100..a8e4756d92 100644 --- a/docs/manual/sections.html.en +++ b/docs/manual/sections.html.en @@ -57,10 +57,12 @@ The order of merging is: </LI> - <LI><CODE><Files></CODE> and <CODE><FilesMatch></CODE> done simultaneously + <LI><CODE><Files></CODE> and <CODE><FilesMatch></CODE> done + simultaneously </LI> - <LI><CODE><Location></CODE> and <CODE><LocationMatch></CODE> done simultaneously + <LI><CODE><Location></CODE> and <CODE><LocationMatch></CODE> done + simultaneously </LI> </OL> diff --git a/docs/manual/stopping.html b/docs/manual/stopping.html index 2b65aa8f1c..3d03d4df97 100644 --- a/docs/manual/stopping.html +++ b/docs/manual/stopping.html @@ -38,7 +38,7 @@ Modify those examples to match your <A HREF="mod/core.html#serverroot">ServerRoot</A> and <A HREF="mod/core.html#pidfile">PidFile</A> settings. -<p>As of Apache 1.3 we provide a script <code>src/support/apachectl</code> +<P>As of Apache 1.3 we provide a script <CODE>src/support/apachectl</CODE> which can be used to start, stop, and restart Apache. It may need a little customization for your system, see the comments at the top of the script. @@ -64,14 +64,15 @@ serving hits. will notice that the server statistics are set to zero when a <CODE>HUP</CODE> is sent. -<P><STRONG>Note:</STRONG> If your configuration file has errors in it when you issue a +<P><STRONG>Note:</STRONG> If your configuration file has errors in it when +you issue a restart then your parent will not restart, it will exit with an error. See below for a method of avoiding this. <H3>USR1 Signal: graceful restart</H3> -<P><STRONG>Note:</STRONG> prior to release 1.2b9 this code is quite unstable and -shouldn't be used at all. +<P><STRONG>Note:</STRONG> prior to release 1.2b9 this code is quite unstable +and shouldn't be used at all. <P>The <CODE>USR1</CODE> signal causes the parent process to <EM>advise</EM> the children to exit after their current request (or to exit immediately @@ -94,7 +95,8 @@ with the StartServers parameter. <P>Users of the <A HREF="mod/mod_status.html">status module</A> will notice that the server statistics -are <STRONG>not</STRONG> set to zero when a <CODE>USR1</CODE> is sent. The code +are <STRONG>not</STRONG> set to zero when a <CODE>USR1</CODE> is sent. The +code was written to both minimize the time in which the server is unable to serve new requests (they will be queued up by the operating system, so they're not lost in any event) and to respect your tuning parameters. In order @@ -113,7 +115,8 @@ old log. For example if most of your hits take less than 10 minutes to complete for users on low bandwidth links then you could wait 15 minutes before doing anything with the old log. -<P><STRONG>Note:</STRONG> If your configuration file has errors in it when you issue a +<P><STRONG>Note:</STRONG> If your configuration file has errors in it when +you issue a restart then your parent will not restart, it will exit with an error. In the case of graceful restarts it will also leave children running when it exits. (These are diff --git a/docs/manual/stopping.html.en b/docs/manual/stopping.html.en index 2b65aa8f1c..3d03d4df97 100644 --- a/docs/manual/stopping.html.en +++ b/docs/manual/stopping.html.en @@ -38,7 +38,7 @@ Modify those examples to match your <A HREF="mod/core.html#serverroot">ServerRoot</A> and <A HREF="mod/core.html#pidfile">PidFile</A> settings. -<p>As of Apache 1.3 we provide a script <code>src/support/apachectl</code> +<P>As of Apache 1.3 we provide a script <CODE>src/support/apachectl</CODE> which can be used to start, stop, and restart Apache. It may need a little customization for your system, see the comments at the top of the script. @@ -64,14 +64,15 @@ serving hits. will notice that the server statistics are set to zero when a <CODE>HUP</CODE> is sent. -<P><STRONG>Note:</STRONG> If your configuration file has errors in it when you issue a +<P><STRONG>Note:</STRONG> If your configuration file has errors in it when +you issue a restart then your parent will not restart, it will exit with an error. See below for a method of avoiding this. <H3>USR1 Signal: graceful restart</H3> -<P><STRONG>Note:</STRONG> prior to release 1.2b9 this code is quite unstable and -shouldn't be used at all. +<P><STRONG>Note:</STRONG> prior to release 1.2b9 this code is quite unstable +and shouldn't be used at all. <P>The <CODE>USR1</CODE> signal causes the parent process to <EM>advise</EM> the children to exit after their current request (or to exit immediately @@ -94,7 +95,8 @@ with the StartServers parameter. <P>Users of the <A HREF="mod/mod_status.html">status module</A> will notice that the server statistics -are <STRONG>not</STRONG> set to zero when a <CODE>USR1</CODE> is sent. The code +are <STRONG>not</STRONG> set to zero when a <CODE>USR1</CODE> is sent. The +code was written to both minimize the time in which the server is unable to serve new requests (they will be queued up by the operating system, so they're not lost in any event) and to respect your tuning parameters. In order @@ -113,7 +115,8 @@ old log. For example if most of your hits take less than 10 minutes to complete for users on low bandwidth links then you could wait 15 minutes before doing anything with the old log. -<P><STRONG>Note:</STRONG> If your configuration file has errors in it when you issue a +<P><STRONG>Note:</STRONG> If your configuration file has errors in it when +you issue a restart then your parent will not restart, it will exit with an error. In the case of graceful restarts it will also leave children running when it exits. (These are diff --git a/docs/manual/suexec.html b/docs/manual/suexec.html index ecdf0c3559..d005739b63 100644 --- a/docs/manual/suexec.html +++ b/docs/manual/suexec.html @@ -74,8 +74,8 @@ may have on your system and its level of security. <P ALIGN="LEFT"> Third, it is assumed that you are using an <STRONG>unmodified</STRONG> version of suEXEC code. All code for suEXEC has been carefully scrutinized and -tested by the developers as well as numerous beta testers. Every precaution has -been taken to ensure a simple yet solidly safe base of code. Altering this +tested by the developers as well as numerous beta testers. Every precaution +has been taken to ensure a simple yet solidly safe base of code. Altering this code can cause unexpected problems and new security risks. It is <STRONG>highly</STRONG> recommended you not alter the suEXEC code unless you are well versed in the particulars of security programming and are willing to @@ -124,124 +124,150 @@ user and group IDs under which the program is to execute. The wrapper then employs the following process to determine success or failure -- if any one of these conditions fail, the program logs the failure and exits with an error, otherwise it will continue: - <OL> - <LI><STRONG>Was the wrapper called with the proper number of arguments?</STRONG> - <BLOCKQUOTE> - The wrapper will only execute if it is given the proper number of arguments. - The proper argument format is known to the Apache web server. If the wrapper - is not receiving the proper number of arguments, it is either being hacked, or - there is something wrong with the suEXEC portion of your Apache binary. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Is the user executing this wrapper a valid user of this system?</STRONG> - <BLOCKQUOTE> - This is to ensure that the user executing the wrapper is truly a user of the system. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Is this valid user allowed to run the wrapper?</STRONG> - <BLOCKQUOTE> - Is this user the user allowed to run this wrapper? Only one user (the Apache - user) is allowed to execute this program. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Does the target program have an unsafe hierarchical reference?</STRONG> - <BLOCKQUOTE> - Does the target program contain a leading '/' or have a '..' backreference? These - are not allowed; the target program must reside within the Apache webspace. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Is the target user name valid?</STRONG> - <BLOCKQUOTE> - Does the target user exist? - </BLOCKQUOTE> - </LI> - <LI><STRONG>Is the target group name valid?</STRONG> - <BLOCKQUOTE> - Does the target group exist? - </BLOCKQUOTE> - </LI> - <LI><STRONG>Is the target user <EM>NOT</EM> superuser?</STRONG> - <BLOCKQUOTE> - Presently, suEXEC does not allow 'root' to execute CGI/SSI programs. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Is the target userid <EM>ABOVE</EM> the minimum ID number?</STRONG> - <BLOCKQUOTE> - The minimum user ID number is specified during configuration. This allows you - to set the lowest possible userid that will be allowed to execute CGI/SSI programs. - This is useful to block out "system" accounts. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Is the target group <EM>NOT</EM> the superuser group?</STRONG> - <BLOCKQUOTE> - Presently, suEXEC does not allow the 'root' group to execute CGI/SSI programs. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Is the target groupid <EM>ABOVE</EM> the minimum ID number?</STRONG> - <BLOCKQUOTE> - The minimum group ID number is specified during configuration. This allows you - to set the lowest possible groupid that will be allowed to execute CGI/SSI programs. - This is useful to block out "system" groups. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Can the wrapper successfully become the target user and group?</STRONG> - <BLOCKQUOTE> - Here is where the program becomes the target user and group via setuid and setgid - calls. The group access list is also initialized with all of the groups of which - the user is a member. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Does the directory in which the program resides exist?</STRONG> - <BLOCKQUOTE> - If it doesn't exist, it can't very well contain files. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Is the directory within the Apache webspace?</STRONG> - <BLOCKQUOTE> - If the request is for a regular portion of the server, is the requested directory - within the server's document root? If the request is for a UserDir, is the requested - directory within the user's document root? - </BLOCKQUOTE> - </LI> - <LI><STRONG>Is the directory <EM>NOT</EM> writable by anyone else?</STRONG> - <BLOCKQUOTE> - We don't want to open up the directory to others; only the owner user may be able - to alter this directories contents. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Does the target program exist?</STRONG> - <BLOCKQUOTE> - If it doesn't exists, it can't very well be executed. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Is the target program <EM>NOT</EM> writable by anyone else?</STRONG> - <BLOCKQUOTE> - We don't want to give anyone other than the owner the ability to change the program. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Is the target program <EM>NOT</EM> setuid or setgid?</STRONG> - <BLOCKQUOTE> - We do not want to execute programs that will then change our UID/GID again. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Is the target user/group the same as the program's user/group?</STRONG> - <BLOCKQUOTE> - Is the user the owner of the file? - </BLOCKQUOTE> - </LI> - <LI><STRONG>Can we successfully clean the process environment to ensure safe operations?</STRONG> - <BLOCKQUOTE> - suEXEC cleans the process' environment by establishing a safe execution PATH (defined - during configuration), as well as only passing through those variables whose names - are listed in the safe environment list (also created during configuration). - </BLOCKQUOTE> - </LI> - <LI><STRONG>Can we successfully become the target program and execute?</STRONG> - <BLOCKQUOTE> - Here is where suEXEC ends and the target program begins. - </BLOCKQUOTE> - </LI> - </OL> +<OL> + <LI><STRONG>Was the wrapper called with the proper number of + arguments?</STRONG> + <BLOCKQUOTE> + The wrapper will only execute if it is given the proper number of arguments. + The proper argument format is known to the Apache web server. If the + wrapper + is not receiving the proper number of arguments, it is either being hacked, + or + there is something wrong with the suEXEC portion of your Apache binary. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Is the user executing this wrapper a valid user of this + system?</STRONG> + <BLOCKQUOTE> + This is to ensure that the user executing the wrapper is truly a user of the + system. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Is this valid user allowed to run the wrapper?</STRONG> + <BLOCKQUOTE> + Is this user the user allowed to run this wrapper? Only one user (the + Apache user) is allowed to execute this program. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Does the target program have an unsafe hierarchical + reference?</STRONG> + <BLOCKQUOTE> + Does the target program contain a leading '/' or have a '..' backreference? + These are not allowed; the target program must reside within the Apache + webspace. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Is the target user name valid?</STRONG> + <BLOCKQUOTE> + Does the target user exist? + </BLOCKQUOTE> + </LI> + <LI><STRONG>Is the target group name valid?</STRONG> + <BLOCKQUOTE> + Does the target group exist? + </BLOCKQUOTE> + </LI> + <LI><STRONG>Is the target user <EM>NOT</EM> superuser?</STRONG> + <BLOCKQUOTE> + Presently, suEXEC does not allow 'root' to execute CGI/SSI programs. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Is the target userid <EM>ABOVE</EM> the minimum ID + number?</STRONG> + <BLOCKQUOTE> + The minimum user ID number is specified during configuration. This allows + you + to set the lowest possible userid that will be allowed to execute CGI/SSI + programs. This is useful to block out "system" accounts. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Is the target group <EM>NOT</EM> the superuser group?</STRONG> + <BLOCKQUOTE> + Presently, suEXEC does not allow the 'root' group to execute CGI/SSI + programs. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Is the target groupid <EM>ABOVE</EM> the minimum ID + number?</STRONG> + <BLOCKQUOTE> + The minimum group ID number is specified during configuration. This allows + you + to set the lowest possible groupid that will be allowed to execute CGI/SSI + programs. This is useful to block out "system" groups. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Can the wrapper successfully become the target user and + group?</STRONG> + <BLOCKQUOTE> + Here is where the program becomes the target user and group via setuid and + setgid + calls. The group access list is also initialized with all of the groups + of which + the user is a member. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Does the directory in which the program resides exist?</STRONG> + <BLOCKQUOTE> + If it doesn't exist, it can't very well contain files. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Is the directory within the Apache webspace?</STRONG> + <BLOCKQUOTE> + If the request is for a regular portion of the server, is the requested + directory + within the server's document root? If the request is for a UserDir, is + the requested + directory within the user's document root? + </BLOCKQUOTE> + </LI> + <LI><STRONG>Is the directory <EM>NOT</EM> writable by anyone else?</STRONG> + <BLOCKQUOTE> + We don't want to open up the directory to others; only the owner user + may be able + to alter this directories contents. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Does the target program exist?</STRONG> + <BLOCKQUOTE> + If it doesn't exists, it can't very well be executed. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Is the target program <EM>NOT</EM> writable by anyone + else?</STRONG> + <BLOCKQUOTE> + We don't want to give anyone other than the owner the ability to + change the program. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Is the target program <EM>NOT</EM> setuid or setgid?</STRONG> + <BLOCKQUOTE> + We do not want to execute programs that will then change our UID/GID again. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Is the target user/group the same as the program's + user/group?</STRONG> + <BLOCKQUOTE> + Is the user the owner of the file? + </BLOCKQUOTE> + </LI> + <LI><STRONG>Can we successfully clean the process environment to + ensure safe operations?</STRONG> + <BLOCKQUOTE> + suEXEC cleans the process' environment by establishing a safe + execution PATH (defined + during configuration), as well as only passing through those + variables whose names + are listed in the safe environment list (also created during + configuration). + </BLOCKQUOTE> + </LI> + <LI><STRONG>Can we successfully become the target program and + execute?</STRONG> + <BLOCKQUOTE> + Here is where suEXEC ends and the target program begins. + </BLOCKQUOTE> + </LI> +</OL> </P> <P ALIGN="LEFT"> @@ -253,8 +279,9 @@ in mind. <P ALIGN="LEFT"> For more information as to how this security model can limit your possibilities -in regards to server configuration, as well as what security risks can be avoided -with a proper suEXEC setup, see the <A HREF="#beware">"Beware the Jabberwock"</A> +in regards to server configuration, as well as what security risks can be +avoided with a proper suEXEC setup, see the +<A HREF="#beware">"Beware the Jabberwock"</A> section of this document. </P> @@ -393,7 +420,8 @@ user shell, do so now and execute the following commands. </P> <P ALIGN="LEFT"> -<STRONG><CODE>chown root /usr/local/apache/sbin/suexec [ENTER]</CODE></STRONG><BR> +<STRONG><CODE>chown root /usr/local/apache/sbin/suexec [ENTER]</CODE></STRONG> +<BR> <STRONG><CODE>chmod 4711 /usr/local/apache/sbin/suexec [ENTER]</CODE></STRONG> </P> @@ -459,7 +487,9 @@ and the error_log for the server to see where you may have gone astray. <STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG> </P> -<H3><A NAME="jabberwock">Beware the Jabberwock: Warnings & Examples</A></H3> +<H3> +<A NAME="jabberwock">Beware the Jabberwock: Warnings & Examples</A> +</H3> <P ALIGN="LEFT"> <STRONG>NOTE!</STRONG> This section may not be complete. For the latest revision of this section of the documentation, see the Apache Group's diff --git a/docs/manual/suexec.html.en b/docs/manual/suexec.html.en index ecdf0c3559..d005739b63 100644 --- a/docs/manual/suexec.html.en +++ b/docs/manual/suexec.html.en @@ -74,8 +74,8 @@ may have on your system and its level of security. <P ALIGN="LEFT"> Third, it is assumed that you are using an <STRONG>unmodified</STRONG> version of suEXEC code. All code for suEXEC has been carefully scrutinized and -tested by the developers as well as numerous beta testers. Every precaution has -been taken to ensure a simple yet solidly safe base of code. Altering this +tested by the developers as well as numerous beta testers. Every precaution +has been taken to ensure a simple yet solidly safe base of code. Altering this code can cause unexpected problems and new security risks. It is <STRONG>highly</STRONG> recommended you not alter the suEXEC code unless you are well versed in the particulars of security programming and are willing to @@ -124,124 +124,150 @@ user and group IDs under which the program is to execute. The wrapper then employs the following process to determine success or failure -- if any one of these conditions fail, the program logs the failure and exits with an error, otherwise it will continue: - <OL> - <LI><STRONG>Was the wrapper called with the proper number of arguments?</STRONG> - <BLOCKQUOTE> - The wrapper will only execute if it is given the proper number of arguments. - The proper argument format is known to the Apache web server. If the wrapper - is not receiving the proper number of arguments, it is either being hacked, or - there is something wrong with the suEXEC portion of your Apache binary. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Is the user executing this wrapper a valid user of this system?</STRONG> - <BLOCKQUOTE> - This is to ensure that the user executing the wrapper is truly a user of the system. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Is this valid user allowed to run the wrapper?</STRONG> - <BLOCKQUOTE> - Is this user the user allowed to run this wrapper? Only one user (the Apache - user) is allowed to execute this program. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Does the target program have an unsafe hierarchical reference?</STRONG> - <BLOCKQUOTE> - Does the target program contain a leading '/' or have a '..' backreference? These - are not allowed; the target program must reside within the Apache webspace. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Is the target user name valid?</STRONG> - <BLOCKQUOTE> - Does the target user exist? - </BLOCKQUOTE> - </LI> - <LI><STRONG>Is the target group name valid?</STRONG> - <BLOCKQUOTE> - Does the target group exist? - </BLOCKQUOTE> - </LI> - <LI><STRONG>Is the target user <EM>NOT</EM> superuser?</STRONG> - <BLOCKQUOTE> - Presently, suEXEC does not allow 'root' to execute CGI/SSI programs. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Is the target userid <EM>ABOVE</EM> the minimum ID number?</STRONG> - <BLOCKQUOTE> - The minimum user ID number is specified during configuration. This allows you - to set the lowest possible userid that will be allowed to execute CGI/SSI programs. - This is useful to block out "system" accounts. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Is the target group <EM>NOT</EM> the superuser group?</STRONG> - <BLOCKQUOTE> - Presently, suEXEC does not allow the 'root' group to execute CGI/SSI programs. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Is the target groupid <EM>ABOVE</EM> the minimum ID number?</STRONG> - <BLOCKQUOTE> - The minimum group ID number is specified during configuration. This allows you - to set the lowest possible groupid that will be allowed to execute CGI/SSI programs. - This is useful to block out "system" groups. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Can the wrapper successfully become the target user and group?</STRONG> - <BLOCKQUOTE> - Here is where the program becomes the target user and group via setuid and setgid - calls. The group access list is also initialized with all of the groups of which - the user is a member. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Does the directory in which the program resides exist?</STRONG> - <BLOCKQUOTE> - If it doesn't exist, it can't very well contain files. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Is the directory within the Apache webspace?</STRONG> - <BLOCKQUOTE> - If the request is for a regular portion of the server, is the requested directory - within the server's document root? If the request is for a UserDir, is the requested - directory within the user's document root? - </BLOCKQUOTE> - </LI> - <LI><STRONG>Is the directory <EM>NOT</EM> writable by anyone else?</STRONG> - <BLOCKQUOTE> - We don't want to open up the directory to others; only the owner user may be able - to alter this directories contents. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Does the target program exist?</STRONG> - <BLOCKQUOTE> - If it doesn't exists, it can't very well be executed. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Is the target program <EM>NOT</EM> writable by anyone else?</STRONG> - <BLOCKQUOTE> - We don't want to give anyone other than the owner the ability to change the program. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Is the target program <EM>NOT</EM> setuid or setgid?</STRONG> - <BLOCKQUOTE> - We do not want to execute programs that will then change our UID/GID again. - </BLOCKQUOTE> - </LI> - <LI><STRONG>Is the target user/group the same as the program's user/group?</STRONG> - <BLOCKQUOTE> - Is the user the owner of the file? - </BLOCKQUOTE> - </LI> - <LI><STRONG>Can we successfully clean the process environment to ensure safe operations?</STRONG> - <BLOCKQUOTE> - suEXEC cleans the process' environment by establishing a safe execution PATH (defined - during configuration), as well as only passing through those variables whose names - are listed in the safe environment list (also created during configuration). - </BLOCKQUOTE> - </LI> - <LI><STRONG>Can we successfully become the target program and execute?</STRONG> - <BLOCKQUOTE> - Here is where suEXEC ends and the target program begins. - </BLOCKQUOTE> - </LI> - </OL> +<OL> + <LI><STRONG>Was the wrapper called with the proper number of + arguments?</STRONG> + <BLOCKQUOTE> + The wrapper will only execute if it is given the proper number of arguments. + The proper argument format is known to the Apache web server. If the + wrapper + is not receiving the proper number of arguments, it is either being hacked, + or + there is something wrong with the suEXEC portion of your Apache binary. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Is the user executing this wrapper a valid user of this + system?</STRONG> + <BLOCKQUOTE> + This is to ensure that the user executing the wrapper is truly a user of the + system. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Is this valid user allowed to run the wrapper?</STRONG> + <BLOCKQUOTE> + Is this user the user allowed to run this wrapper? Only one user (the + Apache user) is allowed to execute this program. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Does the target program have an unsafe hierarchical + reference?</STRONG> + <BLOCKQUOTE> + Does the target program contain a leading '/' or have a '..' backreference? + These are not allowed; the target program must reside within the Apache + webspace. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Is the target user name valid?</STRONG> + <BLOCKQUOTE> + Does the target user exist? + </BLOCKQUOTE> + </LI> + <LI><STRONG>Is the target group name valid?</STRONG> + <BLOCKQUOTE> + Does the target group exist? + </BLOCKQUOTE> + </LI> + <LI><STRONG>Is the target user <EM>NOT</EM> superuser?</STRONG> + <BLOCKQUOTE> + Presently, suEXEC does not allow 'root' to execute CGI/SSI programs. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Is the target userid <EM>ABOVE</EM> the minimum ID + number?</STRONG> + <BLOCKQUOTE> + The minimum user ID number is specified during configuration. This allows + you + to set the lowest possible userid that will be allowed to execute CGI/SSI + programs. This is useful to block out "system" accounts. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Is the target group <EM>NOT</EM> the superuser group?</STRONG> + <BLOCKQUOTE> + Presently, suEXEC does not allow the 'root' group to execute CGI/SSI + programs. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Is the target groupid <EM>ABOVE</EM> the minimum ID + number?</STRONG> + <BLOCKQUOTE> + The minimum group ID number is specified during configuration. This allows + you + to set the lowest possible groupid that will be allowed to execute CGI/SSI + programs. This is useful to block out "system" groups. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Can the wrapper successfully become the target user and + group?</STRONG> + <BLOCKQUOTE> + Here is where the program becomes the target user and group via setuid and + setgid + calls. The group access list is also initialized with all of the groups + of which + the user is a member. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Does the directory in which the program resides exist?</STRONG> + <BLOCKQUOTE> + If it doesn't exist, it can't very well contain files. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Is the directory within the Apache webspace?</STRONG> + <BLOCKQUOTE> + If the request is for a regular portion of the server, is the requested + directory + within the server's document root? If the request is for a UserDir, is + the requested + directory within the user's document root? + </BLOCKQUOTE> + </LI> + <LI><STRONG>Is the directory <EM>NOT</EM> writable by anyone else?</STRONG> + <BLOCKQUOTE> + We don't want to open up the directory to others; only the owner user + may be able + to alter this directories contents. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Does the target program exist?</STRONG> + <BLOCKQUOTE> + If it doesn't exists, it can't very well be executed. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Is the target program <EM>NOT</EM> writable by anyone + else?</STRONG> + <BLOCKQUOTE> + We don't want to give anyone other than the owner the ability to + change the program. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Is the target program <EM>NOT</EM> setuid or setgid?</STRONG> + <BLOCKQUOTE> + We do not want to execute programs that will then change our UID/GID again. + </BLOCKQUOTE> + </LI> + <LI><STRONG>Is the target user/group the same as the program's + user/group?</STRONG> + <BLOCKQUOTE> + Is the user the owner of the file? + </BLOCKQUOTE> + </LI> + <LI><STRONG>Can we successfully clean the process environment to + ensure safe operations?</STRONG> + <BLOCKQUOTE> + suEXEC cleans the process' environment by establishing a safe + execution PATH (defined + during configuration), as well as only passing through those + variables whose names + are listed in the safe environment list (also created during + configuration). + </BLOCKQUOTE> + </LI> + <LI><STRONG>Can we successfully become the target program and + execute?</STRONG> + <BLOCKQUOTE> + Here is where suEXEC ends and the target program begins. + </BLOCKQUOTE> + </LI> +</OL> </P> <P ALIGN="LEFT"> @@ -253,8 +279,9 @@ in mind. <P ALIGN="LEFT"> For more information as to how this security model can limit your possibilities -in regards to server configuration, as well as what security risks can be avoided -with a proper suEXEC setup, see the <A HREF="#beware">"Beware the Jabberwock"</A> +in regards to server configuration, as well as what security risks can be +avoided with a proper suEXEC setup, see the +<A HREF="#beware">"Beware the Jabberwock"</A> section of this document. </P> @@ -393,7 +420,8 @@ user shell, do so now and execute the following commands. </P> <P ALIGN="LEFT"> -<STRONG><CODE>chown root /usr/local/apache/sbin/suexec [ENTER]</CODE></STRONG><BR> +<STRONG><CODE>chown root /usr/local/apache/sbin/suexec [ENTER]</CODE></STRONG> +<BR> <STRONG><CODE>chmod 4711 /usr/local/apache/sbin/suexec [ENTER]</CODE></STRONG> </P> @@ -459,7 +487,9 @@ and the error_log for the server to see where you may have gone astray. <STRONG><A HREF="suexec.html">BACK TO CONTENTS</A></STRONG> </P> -<H3><A NAME="jabberwock">Beware the Jabberwock: Warnings & Examples</A></H3> +<H3> +<A NAME="jabberwock">Beware the Jabberwock: Warnings & Examples</A> +</H3> <P ALIGN="LEFT"> <STRONG>NOTE!</STRONG> This section may not be complete. For the latest revision of this section of the documentation, see the Apache Group's diff --git a/docs/manual/vhosts/details.html b/docs/manual/vhosts/details.html index 97ac6d824e..b7baf591d3 100644 --- a/docs/manual/vhosts/details.html +++ b/docs/manual/vhosts/details.html @@ -14,7 +14,8 @@ <!--#include virtual="header.html" --> <H1 ALIGN="CENTER">An In-Depth Discussion of Virtual Host Matching</H1> -<P>The virtual host code was completely rewritten in <STRONG>Apache 1.3</STRONG>. +<P>The virtual host code was completely rewritten in +<STRONG>Apache 1.3</STRONG>. This document attempts to explain exactly what Apache does when deciding what virtual host to serve a hit from. With the help of the new <A HREF="../mod/core.html#namevirtualhost"><SAMP>NameVirtualHost</SAMP></A> @@ -120,9 +121,9 @@ first name in its <CODE>VirtualHost</CODE> directive. <P>The complete list of names in the <CODE>VirtualHost</CODE> directive are treated just like a <CODE>ServerAlias</CODE> (but are not overridden by any -<CODE>ServerAlias</CODE> statement) if all names resolve to the same address set. -Note that subsequent <CODE>Port</CODE> statements for this vhost will not affect -the ports assigned in the address set. +<CODE>ServerAlias</CODE> statement) if all names resolve to the same address +set. Note that subsequent <CODE>Port</CODE> statements for this vhost will not +affect the ports assigned in the address set. <P>During initialization a list for each IP address is generated an inserted into an hash table. If the IP address is @@ -144,9 +145,11 @@ the table is optimized for IP addresses which vary in the last octet. <A HREF="../mod/core.html#resourceconfig"><CODE>ResourceConfig</CODE></A>, <A HREF="../mod/core.html#accessconfig"><CODE>AccessConfig</CODE></A>, <A HREF="../mod/core.html#timeout"><CODE>Timeout</CODE></A>, - <A HREF="../mod/core.html#keepalivetimeout"><CODE>KeepAliveTimeout</CODE></A>, + <A HREF="../mod/core.html#keepalivetimeout" + ><CODE>KeepAliveTimeout</CODE></A>, <A HREF="../mod/core.html#keepalive"><CODE>KeepAlive</CODE></A>, - <A HREF="../mod/core.html#maxkeepaliverequests"><CODE>MaxKeepAliveRequests</CODE></A>, + <A HREF="../mod/core.html#maxkeepaliverequests" + ><CODE>MaxKeepAliveRequests</CODE></A>, or <A HREF="../mod/core.html#sendbuffersize"><CODE>SendBufferSize</CODE></A> directive then the respective value is @@ -219,17 +222,17 @@ file. <P>The first vhost on this list (the first vhost in the config file with the specified IP address) has the highest priority and catches any request to an unknown server name or a request without a <CODE>Host:</CODE> -header. +header field. -<P>If the client provided a <CODE>Host:</CODE> header the list is +<P>If the client provided a <CODE>Host:</CODE> header field the list is searched for a matching vhost and the first hit on a <CODE>ServerName</CODE> or <CODE>ServerAlias</CODE> is taken and the request is served from -that vhost. A <CODE>Host:</CODE> header can contain a port number, but +that vhost. A <CODE>Host:</CODE> header field can contain a port number, but Apache always matches against the real port to which the client sent the request. <P>If the client submitted a HTTP/1.0 request without <CODE>Host:</CODE> -header we don't know to what server the client tried to connect and +header field we don't know to what server the client tried to connect and any existing <CODE>ServerPath</CODE> is matched against the URI from the request. The first matching path on the list is used and the request is served from that vhost. @@ -282,7 +285,7 @@ taken to be a proxy request. <P> <LI>For security reasons the port number given in a <CODE>Host:</CODE> - header is never used during the matching process. Apache always + header field is never used during the matching process. Apache always uses the real port to which the client sent the request. <P> @@ -290,7 +293,7 @@ taken to be a proxy request. another <CODE>ServerPath</CODE> directive that appears later in the configuration file, then the former will always be matched and the latter will never be matched. (That is assuming that no - Host header was available to disambiguate the two.) + <CODE>Host:</CODE> header field was available to disambiguate the two.) <P> <LI>If two IP-based vhosts have an address in common, the vhost appearing @@ -312,13 +315,13 @@ taken to be a proxy request. and port number to which the client connected is unspecified and does not match any other vhost (including a <CODE>_default_</CODE> vhost). In other words the main_server only catches a request for an - unspecified address/port combination (unless there is a <CODE>_default_</CODE> - vhost which matches that port). + unspecified address/port combination (unless there is a + <CODE>_default_</CODE> vhost which matches that port). <P> <LI>A <CODE>_default_</CODE> vhost or the main_server is <EM>never</EM> matched for a request with an unknown or missing <CODE>Host:</CODE> header - if the client connected to an address (and port) which is used + field if the client connected to an address (and port) which is used for name-based vhosts, e.g. in a <CODE>NameVirtualHost</CODE> directive. <P> diff --git a/docs/manual/vhosts/details_1_2.html b/docs/manual/vhosts/details_1_2.html index 640de6d88d..e262cb3556 100644 --- a/docs/manual/vhosts/details_1_2.html +++ b/docs/manual/vhosts/details_1_2.html @@ -357,7 +357,7 @@ the virtual hosts). </UL> -<H3><A name="whatworks">What Works</A></H3> +<H3><A NAME="whatworks">What Works</A></H3> <P>In addition to the tips on the <A HREF="dns-caveats.html#tips">DNS Issues</A> page, here are some further tips: diff --git a/docs/manual/vhosts/host.html b/docs/manual/vhosts/host.html index 977a2eeb8c..0065e04861 100644 --- a/docs/manual/vhosts/host.html +++ b/docs/manual/vhosts/host.html @@ -135,8 +135,8 @@ workaround, albeit a slightly cumbersome one:</P> <P>To continue the <CODE>www.apache.org</CODE> example (Note: Apache's web server does not actually function in this manner), we might use the -new <CODE>ServerPath</CODE> directive in the <CODE>www.apache.org</CODE> virtual host, -for example: +new <CODE>ServerPath</CODE> directive in the <CODE>www.apache.org</CODE> +virtual host, for example: <PRE> ServerPath /apache diff --git a/docs/manual/vhosts/index.html b/docs/manual/vhosts/index.html index be02eaa4d7..b08ea16444 100644 --- a/docs/manual/vhosts/index.html +++ b/docs/manual/vhosts/index.html @@ -53,8 +53,8 @@ of virtual host support in Apache version 1.3 and later.</P> <LI><A HREF="../mod/core.html#serverpath">ServerPath</A> </UL> -<p>Folks trying to debug their virtual host configuration may find the -Apache <code>-S</code> command line switch useful. It will dump out a +<P>Folks trying to debug their virtual host configuration may find the +Apache <CODE>-S</CODE> command line switch useful. It will dump out a description of how Apache parsed the configuration file. Careful examination of the IP addresses and server names may help uncover configuration mistakes. diff --git a/docs/manual/vhosts/index.html.en b/docs/manual/vhosts/index.html.en index be02eaa4d7..b08ea16444 100644 --- a/docs/manual/vhosts/index.html.en +++ b/docs/manual/vhosts/index.html.en @@ -53,8 +53,8 @@ of virtual host support in Apache version 1.3 and later.</P> <LI><A HREF="../mod/core.html#serverpath">ServerPath</A> </UL> -<p>Folks trying to debug their virtual host configuration may find the -Apache <code>-S</code> command line switch useful. It will dump out a +<P>Folks trying to debug their virtual host configuration may find the +Apache <CODE>-S</CODE> command line switch useful. It will dump out a description of how Apache parsed the configuration file. Careful examination of the IP addresses and server names may help uncover configuration mistakes. diff --git a/docs/manual/vhosts/name-based.html b/docs/manual/vhosts/name-based.html index 3d0190ef95..1a86a32f70 100644 --- a/docs/manual/vhosts/name-based.html +++ b/docs/manual/vhosts/name-based.html @@ -64,9 +64,9 @@ all that is needed is to make sure that the name <SAMP>www.domain.tld</SAMP> points to the IP address <SAMP>111.22.33.44</SAMP></P> -<p>Note: When you specify an IP address in a <code>NameVirtualHost</code> +<P>Note: When you specify an IP address in a <CODE>NameVirtualHost</CODE> directive then requests to that IP address will only ever be served -by matching <VirtualHost>s. The "main server" will <b>never</b> +by matching <VirtualHost>s. The "main server" will <STRONG>never</STRONG> be served from the specified IP address. <P>Additionally, many servers may wish to be accessible by more than diff --git a/docs/manual/vhosts/name-based.html.en b/docs/manual/vhosts/name-based.html.en index 3d0190ef95..1a86a32f70 100644 --- a/docs/manual/vhosts/name-based.html.en +++ b/docs/manual/vhosts/name-based.html.en @@ -64,9 +64,9 @@ all that is needed is to make sure that the name <SAMP>www.domain.tld</SAMP> points to the IP address <SAMP>111.22.33.44</SAMP></P> -<p>Note: When you specify an IP address in a <code>NameVirtualHost</code> +<P>Note: When you specify an IP address in a <CODE>NameVirtualHost</CODE> directive then requests to that IP address will only ever be served -by matching <VirtualHost>s. The "main server" will <b>never</b> +by matching <VirtualHost>s. The "main server" will <STRONG>never</STRONG> be served from the specified IP address. <P>Additionally, many servers may wish to be accessible by more than diff --git a/docs/manual/vhosts/vhosts-in-depth.html b/docs/manual/vhosts/vhosts-in-depth.html index 640de6d88d..e262cb3556 100644 --- a/docs/manual/vhosts/vhosts-in-depth.html +++ b/docs/manual/vhosts/vhosts-in-depth.html @@ -357,7 +357,7 @@ the virtual hosts). </UL> -<H3><A name="whatworks">What Works</A></H3> +<H3><A NAME="whatworks">What Works</A></H3> <P>In addition to the tips on the <A HREF="dns-caveats.html#tips">DNS Issues</A> page, here are some further tips: diff --git a/docs/manual/vhosts/virtual-host.html b/docs/manual/vhosts/virtual-host.html index 11457f647f..fd3dcb2181 100644 --- a/docs/manual/vhosts/virtual-host.html +++ b/docs/manual/vhosts/virtual-host.html @@ -83,9 +83,10 @@ Use a single daemon when: <H2>Setting up multiple daemons</H2> Create a separate httpd installation for each virtual host. For each installation, use the -<A HREF="mod/core.html#bindaddress">BindAddress</A> directive in the configuration +<A HREF="mod/core.html#bindaddress">BindAddress</A> directive in the +configuration file to select which IP address (or virtual host) that daemon services. -e.g. +<EM>E.g.</EM>, <BLOCKQUOTE><CODE>BindAddress www.smallco.com</CODE></BLOCKQUOTE> This hostname can also be given as an IP address. @@ -99,7 +100,7 @@ The <A HREF="mod/core.html#virtualhost">VirtualHost</A> directive in the <A HREF="mod/core.html#errorlog">ErrorLog</A> and <A HREF="mod/mod_log_config.html#transferlog">TransferLog</A> configuration directives to different values for each virtual host. -e.g. +<EM>E.g.</EM>, <BLOCKQUOTE><CODE> <VirtualHost www.smallco.com><BR> ServerAdmin webmaster@mail.smallco.com<BR> @@ -185,7 +186,8 @@ for the root process. This will exhibit itself as errors in the error log like <OL> <LI>Have a <CODE>csh</CODE> script wrapper around httpd which sets the "rlimit" to some large number, like 512. -<LI>Edit http_main.c to add calls to setrlimit() from main(), along the lines of +<LI>Edit http_main.c to add calls to setrlimit() from main(), along the lines +of <PRE> struct rlimit rlp; |