> Paul Fee wrote... > >> Bryan McQuade wrote: >> Are there any cases where it's important for ap_pass_bridgade to pass >> on an empty brigade? Doesn't sound like it, but since this is a core >> library change I want to double check. > > When handling a CONNECT request, the response will have no body. In > mod_proxy, the CONNECT handler currently skips most filters and writes via > the connection filters. However there is a block of "#if 0" code which > intends to send only a FLUSH bucket down the filter chain. > > That's not quite the case of an entirely empty brigade, but it seems close > enough to warrant highlighting. > > Thanks, > Paul
Can't think of anything else that might suffer from the sudden halt of passing empty brigades down the chain ( unless some 3rd party module using tandem-work filters is using them as 'place-markers' and actually EXPECTS them to show up at some point ) but there MIGHT be at least 2 other considerations... 1. If 'ap_pass_brigade()' becomes hard-wired to simply always return SUCCESS when it sees an empty brigade and it NEVER goes down the chain anymore... then is there ANY possibility this could become a 'lost brigade'? When would it ever get reused/released if it's not even making it down to the core filter set anymore? 2. It doesn't 'feel' right that 'ap_pass_brigade()' should always return SUCCESS when it starts throwing the empty brigades on the floor and does NOT send them down the chain. That seems 'misleading'. The call did NOT actually 'SUCCEED' because ap_pass_brigade() did NOT 'pass the brigade'. Should there be some other ERROR/WARNING level return code instead of always tossing back 'SUCCESS'? Might help with debugging later on or give module writers more options for writing their own 'safety catch' return code check(s) when calling ap_pass_brigade(). Yours Kevin Kiley
