coar 00/08/25 05:08:30
Modified: apidoc api.list dict-request_rec.html
Added: apidoc dict-ap_custom_response.html
Log:
Some minor updates, just clearing them out of my work queue.
Revision Changes Path
1.27 +6 -0 httpd-docs-1.3/apidoc/api.list
Index: api.list
===================================================================
RCS file: /home/cvs/httpd-docs-1.3/apidoc/api.list,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -u -r1.26 -r1.27
--- api.list 2000/08/15 12:02:18 1.26
+++ api.list 2000/08/25 12:08:28 1.27
@@ -97,6 +97,12 @@
|/*\n * Called during modules-init phase\n */\n$*("MyMod/1.0");\
|SA-identity\
|dict-$*.html
+R|ap_custom_response\
+ |void $*(request_rec *r, int status, char *string);\
+ |r->content_type = "text/plain"; \n \
+$*(r, HTTP_FORBIDDEN, "Access denied.\n"); \
+ |\
+ |dict-$*.html
R|ap_get_server_built\
|char *$*(void);\
|char *string;\nstring = $*();\
1.6 +77 -8 httpd-docs-1.3/apidoc/dict-request_rec.html
Index: dict-request_rec.html
===================================================================
RCS file: /home/cvs/httpd-docs-1.3/apidoc/dict-request_rec.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -u -r1.5 -r1.6
--- dict-request_rec.html 2000/08/09 14:01:52 1.5
+++ dict-request_rec.html 2000/08/25 12:08:29 1.6
@@ -62,29 +62,46 @@
<dd>This field is used to record the time the request was received
by the server. This value is stored in local time, not GMT.</dd>
<dt><code><b>const char *status_line</b></code></dt>
+ <dd>This field is reserved to and used by the core server for
+ constructing the status line portion of the response header.</dd>
<dt><code><b>int status</b></code></dt>
+ <dd>This is used to contain the numeric code of the HTTP response
+ status, such as <code>HTTP_NOT_MODIFIED</code>. It is typically
+ not used by modules because the protocol module derives the
+ correct value from module responses and the HTTP specification
+ defining the interaction of header fields.</dd>
<dt><code><b>const char *method</b></code></dt>
<dd>This is a pointer to a string representing the name of the HTTP method
used to make the request, such as "<code>GET</code>", as extracted
- from the <code>r->the_request</code> string.</code></dd>
+ from the <code>r->the_request</code> string. Modules may
+ want to reference this field if they handle extension methods not
+ directly known to the core server and therefore not represented by
+ a numeric value. (See th enext field, <code>method_number</code>.)</dd>
<dt><code><b>int method_number</b></code></dt>
<dd>This field contains a numeric value representing the request
method. The possible values are give mnemonic names prefixed with
- "<code>M_</code>", such as "<code>M_GET</code>" and "<code>M_DELETE</code>".
- See the description of <code>M_GET</code> for additional references and
- information. If the request was made using an unrecognised method,
+ "<code>M_</code>", such as "<code>M_GET</code>" and "<code>M_DELETE</code>"
+ (<i>q.q.v.</i>; see the description of <code>M_GET</code> for additional
+ references and information.)
+ If the request was made using a method unknown to the core server,
the value in this field will be <code>M_INVALID</code>, even if the
server has been configured to recognise the method (such as with
- the <code>Script</code> directive).</dd>
+ the <code>Script</code> directive). In this case modules should
+ chekc the string value in the <code>method</code> field of the
+ <code>request_rec</code> structure, which immediately precedes this
+ one.</dd>
<dt><code><b>int allowed</b></code></dt>
<dd>This is a bitmask of the HTTP methods permitted for the resource. The
- module that generates the response content needs to set this; it should
+ module that generates the response content is responsible for setting
+ this; it should
do so before or during the content generation phase, before the response
header is sent. This mask is
used solely to create the <code>Allowed</code> response header field.
It's a good idea to set it in an earlier phase if possible, in case
the request method is <code>OPTIONS</code> and will be handled by the
- <code>default_handler</code>.</dd>
+ <code>default_handler</code>. Due to the dependence on hard-coded
+ bitmask values, Apache 1.3 provides no support for listing
+ extension methods in this field.</dd>
<dt><code><b>int sent_bodyct</b></code></dt>
<dd>This field is reserved for use by the core server.</dd>
<dt><code><b>long bytes_sent</b></code></dt>
@@ -111,7 +128,7 @@
<code>headers_in</code> table described below.</dd>
<dt><code><b>long clength</b></code></dt>
<dd>The actual length in bytes of the response body. Set with the
- <code>ap_set_content_length()</code> routine.</dd>
+ <code>ap_set_content_length()</code> routine (<i>q.v.</i>).</dd>
<dt><code><b>long remaining</b></code></dt>
<dd>The number of bytes in the request body that have not yet been read.
This is updated by the server core each time a module asks the server
@@ -123,12 +140,52 @@
<dt><code><b>int read_body</b></code></dt>
<dt><code><b>int read_chunked</b></code></dt>
<dt><code><b>unsigned expecting_100</b></code></dt>
+ <dd>This field is reserved for use by the core server in handling
+ aspects of the HTTP/1.1 protocol.</dd>
<dt><code><b>table *headers_in</b></code></dt>
+ <dd>This table contains a key/value pair for every field in the
+ request header. Some of the fields are also represented in other
+ ways, such as the <code>Range</code> field, but all of the
+ original request header fields are stored in this table in their
+ raw form. Modules must regard this table as read-only.</dd>
<dt><code><b>table *headers_out</b></code></dt>
+ <dd>This table is used to hold the key/value pairs of the
+ header fields to be sent as part of the response. Under certain
+ conditions, such as error responses, the values in this table
+ will <b>not</b> be used in the construction of the response
+ header. Under normal circumstances, however, its contents
+ are merged with those in the <code>r->err_headers_out</code>
+ table to form the response header.</dd>
<dt><code><b>table *err_headers_out</b></code></dt>
+ <dd>Similar to the <code>headers_out</code> table described
+ previously, the contents of this table are used in the
+ formation of the response header. However, the values in
+ <i>this</i> table are <b>always</b> used, even under
+ error conditions. Under normal conditions, they are merged
+ with those in the <code>r->header_out</code> table and
+ the result is used.</dd>
<dt><code><b>table *subprocess_env</b></code></dt>
+ <dd>The name of this field is somewhat misleading. This table contains
+ the names and values of 'environment' variables that are available
+ to subsequent stages of processing for the request. They are
+ set as actual environment variables only if a child process
+ needs to be created, such as for invoking a CGI script.
+ However, these values are also available for use by things
+ such as <code>mod_include</code>, even though no actual
+ subprocess creation is involved.</dd>
<dt><code><b>table *notes</b></code></dt>
+ <dd>This table has no strictly defined purpose; it is generally
+ intended to provide a means for modules to communicate with
+ each other when processing a request, or for different phase
+ handlers of the same module to pass information from phase
+ to another. For example, <code>mod_speling</code> uses this
+ table to pass a list of possible document variants to
+ <code>mod_negotiation</code>.</dd>
<dt><code><b>const char *content_type</b></code></dt>
+ <dd>Specifies the content-type of the respose body (if there is one).
+ Modules should set this field rather than inserting an entry
+ directly into either <code>r->headers_out</code> or
+ <code>r->err_headers_out</code>.</dd>
<dt><code><b>const char *handler</b></code></dt>
<dt><code><b>const char *content_encoding</b></code></dt>
<dt><code><b>const char *content_language</b></code></dt>
@@ -147,4 +204,16 @@
<dt><code><b>void *request_config</b></code></dt>
<dt><code><b>const struct htaccess_result *htaccess</b></code></dt>
<dt><code><b>char *case_preserved_filename</b></code></dt>
+ <dd>This field contains the original translated filename
+ representing the document source (if it actually is a file)
+ before canonicalisation. This is necessary for some
+ situations in which canonicalisation actually modifies the
+ name for later use. For example, on Windows systems Apache
+ always always translates filenames to lowercase for
+ security reasons (among others). This would cause problems
+ if the case of the requested name was actually significant
+ though the case of the actual filename was not, such as
+ if the request was referring to a Java class file. This
+ field provides the original filename before the downcasing
+ (or other canonicalisation transform) has been performed.</dd>
</dl>
1.1 httpd-docs-1.3/apidoc/dict-ap_custom_response.html
Index: dict-ap_custom_response.html
===================================================================
<p>
This routine permits modules to provide a custom response body for
error pages instead of the standard ones provided by the core
server. This function has an effect quite similar to that of the
<code>ErrorDocument</code> directive, except that the API routine
only supplies a response body for the specified request rather than
a general one for all responses with the indicated status code, and the
body is a string, rather than a script or something to be invoked.
</p>
Modified: apidoc api.list dict-request_rec.html
Added: apidoc dict-ap_custom_response.html
Log:
Some minor updates, just clearing them out of my work queue.
Revision Changes Path
1.27 +6 -0 httpd-docs-1.3/apidoc/api.list
Index: api.list
===================================================================
RCS file: /home/cvs/httpd-docs-1.3/apidoc/api.list,v
retrieving revision 1.26
retrieving revision 1.27
diff -u -u -r1.26 -r1.27
--- api.list 2000/08/15 12:02:18 1.26
+++ api.list 2000/08/25 12:08:28 1.27
@@ -97,6 +97,12 @@
|/*\n * Called during modules-init phase\n */\n$*("MyMod/1.0");\
|SA-identity\
|dict-$*.html
+R|ap_custom_response\
+ |void $*(request_rec *r, int status, char *string);\
+ |r->content_type = "text/plain"; \n \
+$*(r, HTTP_FORBIDDEN, "Access denied.\n"); \
+ |\
+ |dict-$*.html
R|ap_get_server_built\
|char *$*(void);\
|char *string;\nstring = $*();\
1.6 +77 -8 httpd-docs-1.3/apidoc/dict-request_rec.html
Index: dict-request_rec.html
===================================================================
RCS file: /home/cvs/httpd-docs-1.3/apidoc/dict-request_rec.html,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -u -r1.5 -r1.6
--- dict-request_rec.html 2000/08/09 14:01:52 1.5
+++ dict-request_rec.html 2000/08/25 12:08:29 1.6
@@ -62,29 +62,46 @@
<dd>This field is used to record the time the request was received
by the server. This value is stored in local time, not GMT.</dd>
<dt><code><b>const char *status_line</b></code></dt>
+ <dd>This field is reserved to and used by the core server for
+ constructing the status line portion of the response header.</dd>
<dt><code><b>int status</b></code></dt>
+ <dd>This is used to contain the numeric code of the HTTP response
+ status, such as <code>HTTP_NOT_MODIFIED</code>. It is typically
+ not used by modules because the protocol module derives the
+ correct value from module responses and the HTTP specification
+ defining the interaction of header fields.</dd>
<dt><code><b>const char *method</b></code></dt>
<dd>This is a pointer to a string representing the name of the HTTP method
used to make the request, such as "<code>GET</code>", as extracted
- from the <code>r->the_request</code> string.</code></dd>
+ from the <code>r->the_request</code> string. Modules may
+ want to reference this field if they handle extension methods not
+ directly known to the core server and therefore not represented by
+ a numeric value. (See th enext field, <code>method_number</code>.)</dd>
<dt><code><b>int method_number</b></code></dt>
<dd>This field contains a numeric value representing the request
method. The possible values are give mnemonic names prefixed with
- "<code>M_</code>", such as "<code>M_GET</code>" and "<code>M_DELETE</code>".
- See the description of <code>M_GET</code> for additional references and
- information. If the request was made using an unrecognised method,
+ "<code>M_</code>", such as "<code>M_GET</code>" and "<code>M_DELETE</code>"
+ (<i>q.q.v.</i>; see the description of <code>M_GET</code> for additional
+ references and information.)
+ If the request was made using a method unknown to the core server,
the value in this field will be <code>M_INVALID</code>, even if the
server has been configured to recognise the method (such as with
- the <code>Script</code> directive).</dd>
+ the <code>Script</code> directive). In this case modules should
+ chekc the string value in the <code>method</code> field of the
+ <code>request_rec</code> structure, which immediately precedes this
+ one.</dd>
<dt><code><b>int allowed</b></code></dt>
<dd>This is a bitmask of the HTTP methods permitted for the resource. The
- module that generates the response content needs to set this; it should
+ module that generates the response content is responsible for setting
+ this; it should
do so before or during the content generation phase, before the response
header is sent. This mask is
used solely to create the <code>Allowed</code> response header field.
It's a good idea to set it in an earlier phase if possible, in case
the request method is <code>OPTIONS</code> and will be handled by the
- <code>default_handler</code>.</dd>
+ <code>default_handler</code>. Due to the dependence on hard-coded
+ bitmask values, Apache 1.3 provides no support for listing
+ extension methods in this field.</dd>
<dt><code><b>int sent_bodyct</b></code></dt>
<dd>This field is reserved for use by the core server.</dd>
<dt><code><b>long bytes_sent</b></code></dt>
@@ -111,7 +128,7 @@
<code>headers_in</code> table described below.</dd>
<dt><code><b>long clength</b></code></dt>
<dd>The actual length in bytes of the response body. Set with the
- <code>ap_set_content_length()</code> routine.</dd>
+ <code>ap_set_content_length()</code> routine (<i>q.v.</i>).</dd>
<dt><code><b>long remaining</b></code></dt>
<dd>The number of bytes in the request body that have not yet been read.
This is updated by the server core each time a module asks the server
@@ -123,12 +140,52 @@
<dt><code><b>int read_body</b></code></dt>
<dt><code><b>int read_chunked</b></code></dt>
<dt><code><b>unsigned expecting_100</b></code></dt>
+ <dd>This field is reserved for use by the core server in handling
+ aspects of the HTTP/1.1 protocol.</dd>
<dt><code><b>table *headers_in</b></code></dt>
+ <dd>This table contains a key/value pair for every field in the
+ request header. Some of the fields are also represented in other
+ ways, such as the <code>Range</code> field, but all of the
+ original request header fields are stored in this table in their
+ raw form. Modules must regard this table as read-only.</dd>
<dt><code><b>table *headers_out</b></code></dt>
+ <dd>This table is used to hold the key/value pairs of the
+ header fields to be sent as part of the response. Under certain
+ conditions, such as error responses, the values in this table
+ will <b>not</b> be used in the construction of the response
+ header. Under normal circumstances, however, its contents
+ are merged with those in the <code>r->err_headers_out</code>
+ table to form the response header.</dd>
<dt><code><b>table *err_headers_out</b></code></dt>
+ <dd>Similar to the <code>headers_out</code> table described
+ previously, the contents of this table are used in the
+ formation of the response header. However, the values in
+ <i>this</i> table are <b>always</b> used, even under
+ error conditions. Under normal conditions, they are merged
+ with those in the <code>r->header_out</code> table and
+ the result is used.</dd>
<dt><code><b>table *subprocess_env</b></code></dt>
+ <dd>The name of this field is somewhat misleading. This table contains
+ the names and values of 'environment' variables that are available
+ to subsequent stages of processing for the request. They are
+ set as actual environment variables only if a child process
+ needs to be created, such as for invoking a CGI script.
+ However, these values are also available for use by things
+ such as <code>mod_include</code>, even though no actual
+ subprocess creation is involved.</dd>
<dt><code><b>table *notes</b></code></dt>
+ <dd>This table has no strictly defined purpose; it is generally
+ intended to provide a means for modules to communicate with
+ each other when processing a request, or for different phase
+ handlers of the same module to pass information from phase
+ to another. For example, <code>mod_speling</code> uses this
+ table to pass a list of possible document variants to
+ <code>mod_negotiation</code>.</dd>
<dt><code><b>const char *content_type</b></code></dt>
+ <dd>Specifies the content-type of the respose body (if there is one).
+ Modules should set this field rather than inserting an entry
+ directly into either <code>r->headers_out</code> or
+ <code>r->err_headers_out</code>.</dd>
<dt><code><b>const char *handler</b></code></dt>
<dt><code><b>const char *content_encoding</b></code></dt>
<dt><code><b>const char *content_language</b></code></dt>
@@ -147,4 +204,16 @@
<dt><code><b>void *request_config</b></code></dt>
<dt><code><b>const struct htaccess_result *htaccess</b></code></dt>
<dt><code><b>char *case_preserved_filename</b></code></dt>
+ <dd>This field contains the original translated filename
+ representing the document source (if it actually is a file)
+ before canonicalisation. This is necessary for some
+ situations in which canonicalisation actually modifies the
+ name for later use. For example, on Windows systems Apache
+ always always translates filenames to lowercase for
+ security reasons (among others). This would cause problems
+ if the case of the requested name was actually significant
+ though the case of the actual filename was not, such as
+ if the request was referring to a Java class file. This
+ field provides the original filename before the downcasing
+ (or other canonicalisation transform) has been performed.</dd>
</dl>
1.1 httpd-docs-1.3/apidoc/dict-ap_custom_response.html
Index: dict-ap_custom_response.html
===================================================================
<p>
This routine permits modules to provide a custom response body for
error pages instead of the standard ones provided by the core
server. This function has an effect quite similar to that of the
<code>ErrorDocument</code> directive, except that the API routine
only supplies a response body for the specified request rather than
a general one for all responses with the indicated status code, and the
body is a string, rather than a script or something to be invoked.
</p>