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 <> 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.
mod-security-users mailing list
ModSecurity Services from Trustwave's SpiderLabs: