Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Date: Sat, 8 Jun 2002 01:02:32 -0700
From: Greg Stein <gstein@lyra.org>
To: Justin Erenkrantz <jerenkrantz@apache.org>, dev@httpd.apache.org
Subject: Re: Extending ap_register_*_filter
Message-ID: <20020608010232.A11637@lyra.org>
References: <20020607135121.G19485@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <20020607135121.G19485@apache.org>;
 from jerenkrantz@apache.org on Fri, Jun 07, 2002 at 01:51:21PM -0700

On Fri, Jun 07, 2002 at 01:51:21PM -0700, Justin Erenkrantz wrote:
> In discussions about how to properly handle 304 (not modified), it
> seems to me that we need a way for a filter to explicitly run some
> code before the handler (and hence any data is generated) is
> executed.
>...
> This is the best and cleanest solution I can come up with.  Does
> anyone see any problems with this?  I will most likely take a pass
> at implementing this tonight and post a patch for review.  -- justin

This feels totally extraneous to me. The 'insert_filter' hook is defined to
run *right before* the handler is called. It is the absolute latest hook. It
would seem there is no difference between using that one and any kind of
init-filter hook.

(in fact, filter initialization is/can also be done as the filter is
 inserted. the caller can initialize the context for use by the filter)

Just what is the benefit of this relative to inserting a filter with a
specific context, and/or by using the insert_filter hook.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/