From 39238ea91320de27d7db2497d35fbc4504b1c4be Mon Sep 17 00:00:00 2001 From: "Roy T. Fielding" Date: Sun, 7 Mar 1999 15:05:32 +0000 Subject: [PATCH] Added ap_sub_req_method_uri() for doing a subrequest with a method other than GET, and const'd the definition of method in request_rec. Submitted by: Greg Stein Reviewed by: Roy Fielding, Dean Gaudet, Doug MacEachern git-svn-id: https://svn.apache.org/repos/asf/httpd/httpd/trunk@82870 13f79535-47bb-0310-9956-ffa450edef68 --- docs/manual/developer/API.html | 14 ++++++++------ docs/manual/misc/API.html | 14 ++++++++------ 2 files changed, 16 insertions(+), 12 deletions(-) diff --git a/docs/manual/developer/API.html b/docs/manual/developer/API.html index 9595472d8f..bf0fb77d7a 100644 --- a/docs/manual/developer/API.html +++ b/docs/manual/developer/API.html @@ -360,8 +360,9 @@ a few exceptions: order to figure out what icon to use.

Such handlers can construct a sub-request, using the - functions ap_sub_req_lookup_file and - ap_sub_req_lookup_uri; this constructs a new + functions ap_sub_req_lookup_file, + ap_sub_req_lookup_uri, and + ap_sub_req_method_uri; these construct a new request_rec structure and processes it as you would expect, up to but not including the point of actually sending a response. (These functions skip over the access @@ -370,7 +371,7 @@ a few exceptions: (Server-side includes work by building sub-requests and then actually invoking the response handler for them, via the - function run_sub_request). + function ap_run_sub_req).

Handling requests, declining, and returning error @@ -704,7 +705,8 @@ non-http_main functions as arguments at opportune times. Here they are:
  • for the main request this is a subpool of connection->pool; for subrequests it is a subpool of the parent request's pool.
    • -
  • exists until the end of the request (i.e., destroy_sub_req, or +
  • exists until the end of the request (i.e., + ap_destroy_sub_req, or in child_main after process_request has finished)
  • note that r itself is allocated from r->pool; i.e., @@ -818,7 +820,7 @@ latter case, it is simply gone).

    One final note --- sub-requests have their own resource pools, which are sub-pools of the resource pool for the main request. The polite way to reclaim the resources associated with a sub request which you -have allocated (using the ap_sub_req_lookup_... functions) +have allocated (using the ap_sub_req_... functions) is ap_destroy_sub_req, which frees the resource pool. Before calling this function, be sure to copy anything that you care about which might be allocated in the sub-request's resource pool into @@ -830,7 +832,7 @@ this function; only 2K of memory or so are allocated for a typical sub request, and it will be freed anyway when the main request pool is cleared. It is only when you are allocating many, many sub-requests for a single main request that you should seriously consider the -ap_destroy... functions). +ap_destroy_... functions).

    Configuration, commands and the like

    diff --git a/docs/manual/misc/API.html b/docs/manual/misc/API.html index 9595472d8f..bf0fb77d7a 100644 --- a/docs/manual/misc/API.html +++ b/docs/manual/misc/API.html @@ -360,8 +360,9 @@ a few exceptions: order to figure out what icon to use.

    Such handlers can construct a sub-request, using the - functions ap_sub_req_lookup_file and - ap_sub_req_lookup_uri; this constructs a new + functions ap_sub_req_lookup_file, + ap_sub_req_lookup_uri, and + ap_sub_req_method_uri; these construct a new request_rec structure and processes it as you would expect, up to but not including the point of actually sending a response. (These functions skip over the access @@ -370,7 +371,7 @@ a few exceptions: (Server-side includes work by building sub-requests and then actually invoking the response handler for them, via the - function run_sub_request). + function ap_run_sub_req).

    Handling requests, declining, and returning error @@ -704,7 +705,8 @@ non-http_main functions as arguments at opportune times. Here they are:
  • for the main request this is a subpool of connection->pool; for subrequests it is a subpool of the parent request's pool.
    • -
  • exists until the end of the request (i.e., destroy_sub_req, or +
  • exists until the end of the request (i.e., + ap_destroy_sub_req, or in child_main after process_request has finished)
  • note that r itself is allocated from r->pool; i.e., @@ -818,7 +820,7 @@ latter case, it is simply gone).

    One final note --- sub-requests have their own resource pools, which are sub-pools of the resource pool for the main request. The polite way to reclaim the resources associated with a sub request which you -have allocated (using the ap_sub_req_lookup_... functions) +have allocated (using the ap_sub_req_... functions) is ap_destroy_sub_req, which frees the resource pool. Before calling this function, be sure to copy anything that you care about which might be allocated in the sub-request's resource pool into @@ -830,7 +832,7 @@ this function; only 2K of memory or so are allocated for a typical sub request, and it will be freed anyway when the main request pool is cleared. It is only when you are allocating many, many sub-requests for a single main request that you should seriously consider the -ap_destroy... functions). +ap_destroy_... functions).

    Configuration, commands and the like

    -- 2.40.0