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
