Commit c27b75a9 authored by Ken Coar's avatar Ken Coar
Browse files 

	More documentation consistency cleanup for 1.3.2.


git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82066 13f79535-47bb-0310-9956-ffa450edef68
parent 21d3e1d8

docs/manual/content-negotiation.html

+5 −5
Original line number Diff line number Diff line
@@ -85,7 +85,7 @@ information about each of the variants. This is done in one of two 
ways:



<UL>

  <LI> Using a type map (i.e., a <CODE>*.var</CODE> file) which

  <LI> Using a type map (<EM>i.e.</EM>, a <CODE>*.var</CODE> file) which

       names the files containing the variants explicitly

  <LI> Or using a 'MultiViews' search, where the server does an implicit

       filename pattern match, and chooses from among the results.
@@ -167,8 +167,8 @@ The full list of headers recognized is: 
       <CODE>text/html;&nbsp;level=3</CODE>.

  <DT> <CODE>Content-language:</CODE>

  <DD> The languages of the variant, specified as an Internet standard

       language code (e.g., <CODE>en</CODE> for English,

       <CODE>kr</CODE> for Korean, etc.).

       language code (<EM>e.g.</EM>, <CODE>en</CODE> for English,

       <CODE>kr</CODE> for Korean, <EM>etc.</EM>).

  <DT> <CODE>Content-encoding:</CODE>

  <DD> If the file is compressed, or otherwise encoded, rather than

       containing the actual raw data, this says how that was done.
@@ -491,12 +491,12 @@ hyperlinks: 
Looking at the table above you will notice that it is always possible to

use the name without any extensions  in an hyperlink (<EM>e.g.</EM>, <SAMP>foo</SAMP>).

The advantage is that you can hide the actual type of a

document rsp. file and can change it later, e.g. from <SAMP>html</SAMP>

document rsp. file and can change it later, <EM>e.g.</EM>, from <SAMP>html</SAMP>

to <SAMP>shtml</SAMP> or <SAMP>cgi</SAMP> without changing any

hyperlink references.



<P>

If you want to continue to use a MIME-type in your hyperlinks (e.g.

If you want to continue to use a MIME-type in your hyperlinks (<EM>e.g.</EM>

<SAMP>foo.html</SAMP>) the language extension (including an encoding extension

if there is one) must be on the right hand side of the MIME-type extension

(<EM>e.g.</EM>, <SAMP>foo.html.en</SAMP>).

docs/manual/content-negotiation.html.en

+5 −5
Original line number Diff line number Diff line
@@ -85,7 +85,7 @@ information about each of the variants. This is done in one of two 
ways:



<UL>

  <LI> Using a type map (i.e., a <CODE>*.var</CODE> file) which

  <LI> Using a type map (<EM>i.e.</EM>, a <CODE>*.var</CODE> file) which

       names the files containing the variants explicitly

  <LI> Or using a 'MultiViews' search, where the server does an implicit

       filename pattern match, and chooses from among the results.
@@ -167,8 +167,8 @@ The full list of headers recognized is: 
       <CODE>text/html;&nbsp;level=3</CODE>.

  <DT> <CODE>Content-language:</CODE>

  <DD> The languages of the variant, specified as an Internet standard

       language code (e.g., <CODE>en</CODE> for English,

       <CODE>kr</CODE> for Korean, etc.).

       language code (<EM>e.g.</EM>, <CODE>en</CODE> for English,

       <CODE>kr</CODE> for Korean, <EM>etc.</EM>).

  <DT> <CODE>Content-encoding:</CODE>

  <DD> If the file is compressed, or otherwise encoded, rather than

       containing the actual raw data, this says how that was done.
@@ -491,12 +491,12 @@ hyperlinks: 
Looking at the table above you will notice that it is always possible to

use the name without any extensions  in an hyperlink (<EM>e.g.</EM>, <SAMP>foo</SAMP>).

The advantage is that you can hide the actual type of a

document rsp. file and can change it later, e.g. from <SAMP>html</SAMP>

document rsp. file and can change it later, <EM>e.g.</EM>, from <SAMP>html</SAMP>

to <SAMP>shtml</SAMP> or <SAMP>cgi</SAMP> without changing any

hyperlink references.



<P>

If you want to continue to use a MIME-type in your hyperlinks (e.g.

If you want to continue to use a MIME-type in your hyperlinks (<EM>e.g.</EM>

<SAMP>foo.html</SAMP>) the language extension (including an encoding extension

if there is one) must be on the right hand side of the MIME-type extension

(<EM>e.g.</EM>, <SAMP>foo.html.en</SAMP>).

docs/manual/custom-error.html

+2 −2
Original line number Diff line number Diff line
@@ -54,7 +54,7 @@ 
     more clearly.



  <P>To achieve this, Apache will define new CGI-like environment

     variables, e.g.

     variables, <EM>e.g.</EM>



  <BLOCKQUOTE><CODE>

REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/x-xbitmap, image/jpeg <BR>
@@ -145,7 +145,7 @@ script which has been redirected to. Each new variable will have the 
prefix <CODE>REDIRECT_</CODE>.  <CODE>REDIRECT_</CODE> environment

variables are created from the CGI environment variables which existed

prior to the redirect, they are renamed with a <CODE>REDIRECT_</CODE>

prefix, i.e. <CODE>HTTP_USER_AGENT</CODE> becomes

prefix, <EM>i.e.</EM>, <CODE>HTTP_USER_AGENT</CODE> becomes

<CODE>REDIRECT_HTTP_USER_AGENT</CODE>.  In addition to these new

variables, Apache will define <CODE>REDIRECT_URL</CODE> and

<CODE>REDIRECT_STATUS</CODE> to help the script trace its origin.

docs/manual/custom-error.html.en

+2 −2
Original line number Diff line number Diff line
@@ -54,7 +54,7 @@ 
     more clearly.



  <P>To achieve this, Apache will define new CGI-like environment

     variables, e.g.

     variables, <EM>e.g.</EM>



  <BLOCKQUOTE><CODE>

REDIRECT_HTTP_ACCEPT=*/*, image/gif, image/x-xbitmap, image/jpeg <BR>
@@ -145,7 +145,7 @@ script which has been redirected to. Each new variable will have the 
prefix <CODE>REDIRECT_</CODE>.  <CODE>REDIRECT_</CODE> environment

variables are created from the CGI environment variables which existed

prior to the redirect, they are renamed with a <CODE>REDIRECT_</CODE>

prefix, i.e. <CODE>HTTP_USER_AGENT</CODE> becomes

prefix, <EM>i.e.</EM>, <CODE>HTTP_USER_AGENT</CODE> becomes

<CODE>REDIRECT_HTTP_USER_AGENT</CODE>.  In addition to these new

variables, Apache will define <CODE>REDIRECT_URL</CODE> and

<CODE>REDIRECT_STATUS</CODE> to help the script trace its origin.

docs/manual/developer/API.html

+12 −12
Original line number Diff line number Diff line
@@ -14,7 +14,7 @@ 
<H1 ALIGN="CENTER">Apache API notes</H1>



These are some notes on the Apache API and the data structures you

have to deal with, etc.  They are not yet nearly complete, but

have to deal with, <EM>etc.</EM>  They are not yet nearly complete, but

hopefully, they will help you get your bearings.  Keep in mind that

the API is still subject to change as we gain experience with it.

(See the TODO file for what <EM>might</EM> be coming).  However,
@@ -109,7 +109,7 @@ checking, all handlers always run (barring an error). Also, the 
response phase is unique in that modules may declare multiple handlers

for it, via a dispatch table keyed on the MIME type of the requested

object.  Modules may declare a response-phase handler which can handle

<EM>any</EM> request, by giving it the key <CODE>*/*</CODE> (i.e., a

<EM>any</EM> request, by giving it the key <CODE>*/*</CODE> (<EM>i.e.</EM>, a

wildcard MIME type specification).  However, wildcard handlers are

only invoked if the server has already tried and failed to find a more

specific response handler for the MIME type of the requested object
@@ -151,7 +151,7 @@ where they are permitted, and how they are to be invoked. <P> 
A final note on the declared types of the arguments of some of these

commands: a <CODE>pool</CODE> is a pointer to a <EM>resource pool</EM>

structure; these are used by the server to keep track of the memory

which has been allocated, files opened, etc., either to service a

which has been allocated, files opened, <EM>etc.</EM>, either to service a

particular request, or to handle the process of configuring itself.

That way, when the request is over (or, for the configuration pool,

when the server is restarting), the memory can be freed, and the files
@@ -306,8 +306,8 @@ struct request_rec { 


  int header_only;     /* HEAD request, as opposed to GET */

  char *protocol;      /* Protocol, as given to us, or HTTP/0.9 */

  char *method;        /* GET, HEAD, POST, etc. */

  int method_number;   /* M_GET, M_POST, etc. */

  char *method;        /* GET, HEAD, POST, <EM>etc.</EM> */

  int method_number;   /* M_GET, M_POST, <EM>etc.</EM> */



  /* Info for logging */
@@ -325,7 +325,7 @@ struct request_rec { 
   * (the thing pointed to being the module's business).

   */



  void *per_dir_config;   /* Options set in config files, etc. */

  void *per_dir_config;   /* Options set in config files, <EM>etc.</EM> */

  void *request_config;   /* Notes on *this* request */



};
@@ -339,7 +339,7 @@ request from a client, and filling in the fields. However, there are 
a few exceptions:



<UL>

  <LI> If the request is to an imagemap, a type map (i.e., a

  <LI> If the request is to an imagemap, a type map (<EM>i.e.</EM>, a

       <CODE>*.var</CODE> file), or a CGI script which returned a

       local `Location:', then the resource which the user requested

       is going to be ultimately located by some URI other than what
@@ -503,7 +503,7 @@ response was actually sent). 
<P>

One of the problems of writing and designing a server-pool server is

that of preventing leakage, that is, allocating resources (memory,

open files, etc.), without subsequently releasing them.  The resource

open files, <EM>etc.</EM>), without subsequently releasing them.  The resource

pool machinery is designed to make it easy to prevent this from

happening, by allowing resource to be allocated in such a way that

they are <EM>automatically</EM> released when the server is done with
@@ -511,7 +511,7 @@ them. 
</P>

<P>

The way this works is as follows:  the memory which is allocated, file

opened, etc., to deal with a particular request are tied to a

opened, <EM>etc.</EM>, to deal with a particular request are tied to a

<EM>resource pool</EM> which is allocated for the request.  The pool

is a data structure which itself tracks the resources in question.

</P>
@@ -785,7 +785,7 @@ which the file stuff is implemented; also, <CODE>spawn_process</CODE>. 
Pool cleanups live until clear_pool() is called:  clear_pool(a) recursively

calls destroy_pool() on all subpools of a; then calls all the cleanups for a; 

then releases all the memory for a.  destroy_pool(a) calls clear_pool(a) 

and then releases the pool structure itself.  i.e. clear_pool(a) doesn't

and then releases the pool structure itself.  <EM>i.e.</EM>, clear_pool(a) doesn't

delete a, it just frees up all the resources and you can start using it

again immediately. 

</P>
@@ -968,7 +968,7 @@ void *merge_mime_dir_configs (pool *p, void *parent_dirv, void *subdirv) 


As a note --- if there is no per-directory merge function present, the

server will just use the subdirectory's configuration info, and ignore

the parent's.  For some modules, that works just fine (e.g., for the

the parent's.  For some modules, that works just fine (<EM>e.g.</EM>, for the

includes module, whose per-directory configuration information

consists solely of the state of the <CODE>XBITHACK</CODE>), and for

those modules, you can just not declare one, and leave the
@@ -1025,7 +1025,7 @@ command_rec mime_cmds[] = { 
{ "AddType", add_type, NULL, OR_FILEINFO, TAKE2,

    "a mime type followed by a file extension" },

{ "AddEncoding", add_encoding, NULL, OR_FILEINFO, TAKE2,

    "an encoding (e.g., gzip), followed by a file extension" },

    "an encoding (<EM>e.g.</EM>, gzip), followed by a file extension" },

{ NULL }

};

</PRE>