Mailing-List: contact modules-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: modules-dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of
 martin.townsend@power-oasis.com designates 81.19.188.97 as permitted sender)
Message-ID: <4F105AC3.8060104@power-oasis.com>
Date: Fri, 13 Jan 2012 16:24:35 +0000
From: Martin Townsend <martin.townsend@power-oasis.com>
Organization: Power Oasis
User-Agent: Mozilla/5.0 (Windows NT 6.1;
 rv:8.0) Gecko/20111105 Thunderbird/8.0
MIME-Version: 1.0
To: modules-dev@httpd.apache.org
Subject: Re: A few questions on Input Filters
References: <AANLkTinYZ-3id1_km5kvOVQqjGkU00oVCF0=8b5k67BP@mail.gmail.com>
 <6B61A030-4A68-4094-B244-E88C9261B097@apache.org>
 <4F0D6FCA.1010301@power-oasis.com> <4F0DC2EA.4030605@joe-lewis.com>
In-Reply-To: <4F0DC2EA.4030605@joe-lewis.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Thanks Joe for the info, my input filter is now behaving itself again.
I've not seen any FLUSH buckets yet so I doubt I will as we are running 
the bare minimum of modules.  I'll let you know if I do though.
One last question, when I don't see the EOS bucket should I return a 
certain APR_ error code to say the POST request hasn't finished yet. I'm 
currently return APR_OK and this seems to work.

Cheers,
Martin.

On 11/01/2012 17:12, Joe Lewis wrote:
> On 01/11/2012 04:17 AM, Martin Townsend wrote:
>> The problem occured when the POST request was split into two brigades 
>> which are passed independently to my filter. So my first question is 
>> this expected?
>
> You should definitely expect that.  Don't assume that the entire 
> content will always come in the same way.  In this kind of development 
> architecture (where anyone can build a module), we should expect the 
> unexpected.
>
>>   I assume it is so I have to alter my filter to handle partial 
>> bucket brigades.
>> If so, I take it I can infer a partial brigade by the fact that the 
>> EOS bucket is not present?
>> Whilst looking through other input filters I notice they handle FLUSH 
>> buckets, for my input filter I take it I can ignore these buckets as 
>> all I'm trying to do is extract the POST data to a buffer and then 
>> process it without altering it.
>
> If the brigade doesn't have that EOS, there is more to the stream to 
> be read.  When you see the FLUSH bucket, you should really be passing 
> the brigade on to the next chain (FLUSH buckets are created when the 
> brigade needs to be split).
>
> I had originally thought that FLUSH buckets were output buckets to 
> prevent the client from waiting too long.  Are you seeing these on an 
> input chain?  If so, what other modules are involved?  I'm curious for 
> my own understanding of how other modules might effect some of the 
> stuff I have written.
>
>> I noticed that one module's input filter ignored sub requests, does 
>> anyone know when sub requests occur within the input filter phase and 
>> whether I can ignore these too.
>
> The input's have already been done when a sub request is created.  
> Usually, a sub request is happening when an output filter or a content 
> generator are being called, so I'm not sure a sub-request will see the 
> input from the parent filter.
>
>>
>> Many Thanks,
>> Martin.
>
> That is what the list is for.  Hope you can get things straightened out!
> Joe Lewis
> -- 
> www.silverhawk.net