Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 1730 invoked by uid 6000); 3 Feb 1998 09:45:24 -0000 Received: (qmail 1723 invoked from network); 3 Feb 1998 09:45:23 -0000 Received: from twinlark.arctic.org (204.62.130.91) by taz.hyperreal.org with SMTP; 3 Feb 1998 09:45:23 -0000 Received: (qmail 32622 invoked by uid 500); 3 Feb 1998 09:57:19 -0000 Date: Tue, 3 Feb 1998 01:57:19 -0800 (PST) From: Dean Gaudet To: new-httpd@apache.org Subject: Re: cvs commit: apache-1.3/src/modules/standard mod_include.c In-Reply-To: <19980203093049.16385.qmail@hyperreal.org> Message-ID: X-Comment: Visit http://www.arctic.org/~dgaudet/legal for information regarding copyright and disclaimer. Organization: Transmeta Corp. 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 3 Feb 1998 dgaudet@hyperreal.org wrote: > dgaudet 98/02/03 01:30:49 > > Modified: src/modules/standard mod_include.c > Log: > Here is a more faithful fix for the mod_include/table_xxxn API problem. > We preserve all the original functionality at the expense of some extra > memory because we don't clean up subrequests. > > Plus a bug is fixed -- if mod_include is not the only module using > run_sub_request() then it was possible that add_xxx_vars() wouldn't be > done, and the environment would be incorrect. Before anyone freaks about the "don't clean up subrequests" I should say that I mean "don't clean up mod_include subrequests". I don't feel so bad about this. mod_include prevents recursive includes... users are likely to blow file descriptor limits before they cause any real harm. Dean