Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 9402 invoked by uid 6000); 16 May 1999 23:34:18 -0000 Received: (qmail 9395 invoked from network); 16 May 1999 23:34:17 -0000 Received: from twinlark.arctic.org (204.107.140.52) by taz.hyperreal.org with SMTP; 16 May 1999 23:34:17 -0000 Received: (qmail 6653 invoked by uid 500); 16 May 1999 23:34:16 -0000 Date: Sun, 16 May 1999 16:34:16 -0700 (PDT) From: Dean Gaudet To: new-httpd@apache.org Subject: Re: cvs commit: apache-1.3/src/modules/standard mod_autoindex.c mod_include.c In-Reply-To: <373C67FE.7AFB5E96@rsbx.net> Message-ID: X-Comment: Visit http://www.arctic.org/~dgaudet/legal for information regarding copyright and disclaimer. MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org On Fri, 14 May 1999, Raymond S Brand wrote: > Dean Gaudet wrote: > > /* Kludge --- Doing this allows the caller to safely destroy the > > * sub_req > > */ > > r->pool = ap_make_sub_pool(r->pool); > > > > Sorry, but that's just way off my bogosity meter. > > No more bogus than the current situation in mod_include. Not really, the current situation is that it avoids destroying the subrequest... which has a similar effect, as you point out with the patch you just included. And further, it's local to mod_include. > I fail to see how the above call sequence can happen. Can you flesh it out > some? And are there any ap_*sub_req*() calls in the sequence? It would require some crap in cleanups I'm sure, so I'll stop stretching. But I'm certainly not going to ignore the 2.0 implications w.r.t. context... you can ignore them if you want, but I can't. > The sub_pool business is ONLY there so that a sub_req can be destroyed. I'm > tired of this argument. Use the following; I'm sorry you're tired of this argument, but I'm also of the opinion that something is wrong with the subrequest mechanism and that there is an abstraction we're missing... the stuff which is in mod_include already is an example of something which isn't quite clean -- but is there to support pre-existing functionality. What you're talking about is new functionality. Maybe the abstraction is as simple as a "root environment" or "global environment". Or maybe we need to distinguish between a partial subrequest and a full subrequest -- partial meaning "provides part of the full response object". I don't know. I stopped hacking on this when I got mod_include to work properly without memory corruption. There's still something else I brought up -- I think this is backwards. I don't think mod_autoindex should be bending over to behave like mod_include. I think mod_autoindex should provide a way to be included by mod_include. Dean