Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: modules-dev@httpd.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
References: <BANLkTins4TdTGQDc_=w8iAQ+EB_8rYXEzQ@mail.gmail.com>
 <BANLkTikLmXsoq=Qx9EV6oyb9cMtnAyWgnQ@mail.gmail.com>
In-Reply-To: <BANLkTikLmXsoq=Qx9EV6oyb9cMtnAyWgnQ@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
Message-Id: <8B9518D4-FBE4-4A84-8400-91ACED904D10@apache.org>
Content-Transfer-Encoding: 7bit
From: Nick Kew <niq@apache.org>
Subject: Re: input filters called again after Handler returns
Date: Thu, 30 Jun 2011 10:12:46 +0100
To: modules-dev@httpd.apache.org


On 30 Jun 2011, at 08:11, Sorin Manolache wrote:

> On Thu, Jun 30, 2011 at 02:56, Jodi Bosa <jodibosa@gmail.com> wrote:
>> I'm encountering a strange interaction between modules (including my own).
>> When I track it down, it appears that input filters are called after the
>> handler is finished which results in 2 bodies in the response.
>> 
>> In other words, this is what appears to be happening:
>>        Input filters called with AP_MODE_GETLINE (for each HTTP request
>> header)
>>        Handler called and returns 302
>>        input filters called with AP_MODE_READBYTES and 8192
>> 
>> 
>> I've placed logging in ap_internal_*_redirect() and removed all related
>> modules to see if one was a problem - yet the same issue happens.
>> 
>> Thanks for any help.
>> 
> 
> 
> At the end of the request processing chain, apache places a function
> that clears the request body.
> (ap_finalize_request_protocol->ap_discard_request_body).
> 
> Your inut filter should place an EOS bucket in the brigade or return
> something else than APR_SUCCESS in this second invocation.

Have you encountered the actual problem described?  I haven't.
  
I can see that failing to deal with EOS might cause such an issue,
but I don't see that a filter should want or need self-awareness of
a 'second invocation': rather that would be an issue for whatever
is issuing the internal redirect.

I'm guessing this problematic filter is one that doesn't pass its
(modified) input through to its output?  In which case, it should
take responsibility for reading its input through to EOS and for
returning EOS to its caller.  If you fix that and still have the
problem, please describe in detail!

-- 
Nick Kew

Available for work, contract or permanent
http://www.webthing.com/~nick/cv.html