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