Re: [PATCH] ap_internal_fast_redirect

[Greg Ames]

Justin Erenkrantz wrote:
 
  However, certain modules like mod_deflate attempt to verify
 that it only deals with non-subreq (!r-main) requests.  We can
 see if we can take that check out - not sure if we can or can not
 do that.  

mod_rewrite has r-main checks also.  I'd rather not start tinkering with
mod_rewrite, at least not until we have a golden 2.x release.

Greg

[PATCH] ap_internal_fast_redirect

[Justin Erenkrantz]

Not that I'm advocating committing this, but this is what I'm
using locally in order to get the AddOutputFilterByType directive
to work with mod_dir/mod_negotiation internal redirects.  -- justin

Index: modules/http/http_request.c
===
RCS file: /home/cvs/httpd-2.0/modules/http/http_request.c,v
retrieving revision 1.125
diff -u -r1.125 http_request.c
--- modules/http/http_request.c 25 Jan 2002 01:11:46 -  1.125
+++ modules/http/http_request.c 19 Feb 2002 00:17:05 -
@@ -415,6 +415,8 @@
 /* XXX: Is this function is so bogus and fragile that we deep-6 it? */
 AP_DECLARE(void) ap_internal_fast_redirect(request_rec *rr, request_rec *r)
 {
+ap_filter_t *fnew;
+
 /* We need to tell POOL_DEBUG that we're guaranteeing that rr-pool
  * will exist as long as r-pool.  Otherwise we run into troubles because
  * some values in this request will be allocated in r-pool, and others in
@@ -441,6 +443,27 @@
 r-err_headers_out);
 r-subprocess_env = apr_table_overlay(r-pool, rr-subprocess_env,
r-subprocess_env);
+
+fnew = rr-output_filters;
+while (fnew) {
+ap_filter_t *f;
+int found = 0;
+
+f = r-output_filters;
+while (f) {
+if(!strcasecmp(f-frec-name, fnew-frec-name)) {
+found = 1;
+break;
+}
+f = f-next;
+}
+/* Do not add the subreq_core filter! */
+if (!found  strcasecmp(fnew-frec-name, subreq_core)) {
+ap_add_output_filter(fnew-frec-name, NULL, r, r-connection);
+}
+
+fnew = fnew-next;
+}
 }
 
 AP_DECLARE(void) ap_internal_redirect(const char *new_uri, request_rec *r)

Re: [PATCH] ap_internal_fast_redirect

[Justin Erenkrantz]

On Mon, Feb 18, 2002 at 09:06:08PM -0600, William A. Rowe, Jr. wrote:
 Interesting patch :)  Of course it does not address the output headers
 issue, if I understand that report.

For me, it does.  It simply ensures that any filters that were added
to the subreq are in the main request.  So, that when the subreq
is processed as a main requests, the filters are run too.

 It almost smells like the -subreq- should be processed and the main
 request should simply become a noop if we do a fast internal redirect.
 Does that make any sense?

Totally.  I thought with the subreq_core stuff we already have the
infrastructure to do so.  It'd be better than this bogus promotion
code.  However, certain modules like mod_deflate attempt to verify
that it only deals with non-subreq (!r-main) requests.  We can
see if we can take that check out - not sure if we can or can not
do that.  -- justin