Re: [mod-security-users] Questions about STREAM_INPUT_BODY

[Breno S. <bre...@gm...>]

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 <iva...@gm...> 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 <RBa...@tr...>
> 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" <iva...@gm...>
> 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 <bre...@gm...>
> 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 <iva...@gm...>
> 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...@li...
> >>>> 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...@li...
> >> 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ć
>