httpd-modules-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sorin Manolache <>
Subject Re: input filters called again after Handler returns
Date Thu, 30 Jun 2011 09:44:59 GMT
On Thu, Jun 30, 2011 at 11:12, Nick Kew <> wrote:
> On 30 Jun 2011, at 08:11, Sorin Manolache wrote:
>> On Thu, Jun 30, 2011 at 02:56, Jodi Bosa <> 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 have but indeed my filter did not pass its modified input to its output.

My server got GET requests and had to proxy them to a backend that
wanted POST requests. My input filter was more of a request body
generator for mod_proxy, so it did not read its input (never called


> 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

View raw message