stream* is there to be now reallocable buffers. it will be used in the future for connection level buffers. and i will not do that with reqbody_ and resbody_ data.

Also .. resbody_data is using apr to alloc data which is much more faster that malloc. I don't think is a good idea try to realloc apr data and will make the management for difficult . Also input streams should have all kind of request body... reqbody buffer appears to not have data in some conten-types.

On Thu, Apr 28, 2011 at 1:33 PM, Ivan Ristic <ivan.ristic@gmail.com> wrote:
Well that's the thing. I looked at the code, and there's practically
no difference, and no reason why @rsub can't be made to work with
REQUEST_BODY and RESPONSE_BODY.

Also, the "stream" part of the name is very misleading, because
there's no streaming going on.


On Wed, Apr 27, 2011 at 10:32 PM, Ryan Barnett <RBarnett@trustwave.com> wrote:
> Breno has the details but the difference is that the STREAM_ variables can be swapped back into the live transaction for data modification.
>
> On Apr 27, 2011, at 5:17 PM, "Ivan Ristic" <ivan.ristic@gmail.com> wrote:
>
>> I think you should have reused REQUEST_BODY, seeing that the only
>> thing different about STREAM_INPUT_BODY is that it is always there
>> (whereas REQUEST_BODY is only there for
>> application/x-www-form-urlencoded C-T). The SecStreamInBodyInspection
>> could have easily controlled the presence of REQUEST_BODY.
>>
>>
>> On Wed, Apr 27, 2011 at 9:17 PM, Breno Silva <breno.silva@gmail.com> wrote:
>>> STREAM_* variables are similar to its pairs body buffers. It runs in the
>>> same phase and the limits should work the same.
>>> However STREAM_* are created to be reallocable buffer for more complex data
>>> modifications like rsub operators and others in the future.
>>>
>>> When you enable SecStream* directives you will consume more memory.
>>>
>>> On Wed, Apr 27, 2011 at 2:58 PM, Ivan Ristic <ivan.ristic@gmail.com> wrote:
>>>>
>>>> I have a couple of questions about STREAM_INPUT_BODY:
>>>>
>>>> - For STREAM_INPUT_BODY, the manual states that using @pm with it is
>>>> better because the matching takes place before phase 2. But when I
>>>> look at my debug logs, I see the @pm rule against STREAM_INPUT_BODY
>>>> execute in phase 2, just as any other rule.
>>>>
>>>> - STREAM_INPUT_BODY contains the raw request body, no matter of
>>>> content type -- is that correct?
>>>>
>>>> - What is the impact on memory consumption when
>>>> SecStreamInBodyInspection is enabled?
>>>>
>>>> - Is the maximum size of the buffer still controlled with
>>>> SecRequestBodyLimit?
>>>>
>>>> - Does that mean that when SecStreamInBodyInspection is enabled, it
>>>> effectively breaks the safety provided by SecRequestBodyNoFilesLimit
>>>> (meaning that large file uploads will be fully buffered in RAM)?
>>>>
>>>> --
>>>> Ivan Ristić
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> WhatsUp Gold - Download Free Network Management Software
>>>> The most intuitive, comprehensive, and cost-effective network
>>>> management toolset available today.  Delivers lowest initial
>>>> acquisition cost and overall TCO of any competing solution.
>>>> http://p.sf.net/sfu/whatsupgold-sd
>>>> _______________________________________________
>>>> mod-security-users mailing list
>>>> mod-security-users@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>>>> ModSecurity Services from Trustwave's SpiderLabs:
>>>> https://www.trustwave.com/spiderLabs.php
>>>
>>>
>>
>>
>>
>> --
>> Ivan Ristić
>>
>> ------------------------------------------------------------------------------
>> WhatsUp Gold - Download Free Network Management Software
>> The most intuitive, comprehensive, and cost-effective network
>> management toolset available today.  Delivers lowest initial
>> acquisition cost and overall TCO of any competing solution.
>> http://p.sf.net/sfu/whatsupgold-sd
>> _______________________________________________
>> mod-security-users mailing list
>> mod-security-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mod-security-users
>> ModSecurity Services from Trustwave's SpiderLabs:
>> https://www.trustwave.com/spiderLabs.php
>
> This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
>



--
Ivan Ristić