httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From c...@locus.apache.org
Subject cvs commit: httpd-docs-1.3/apidoc dict-ap_custom_response.html api.list dict-request_rec.html
Date Fri, 25 Aug 2000 12:08:31 GMT
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-&gt;the_request</code> string.</code></dd>
  +  from the <code>r-&gt;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-&gt;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-&gt;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-&gt;headers_out</code> or
  +  <code>r-&gt;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>
  
  
  

Mime
View raw message