httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ivan Ristic" <ivan.ris...@gmail.com>
Subject Re: Limiting response body length
Date Tue, 13 Feb 2007 11:30:32 GMT
On 2/13/07, Dziugas Baltrunas <dziugas@gmail.com> wrote:
> Hi list,
>
> thanks for the replies. Looks like squid in case Content-Length
> response header is missing, does it's limitation in a "hard" way (snip
> from src/client_side.c):
>
>     } else if (clientReplyBodyTooLarge(http, http->out.offset - 4096)) {
>         /* 4096 is a margin for the HTTP headers included in out.offset */
>         comm_close(fd);
>     } else {
>
> However this seems to be the only way in case we want to avoid content
> buffering. mod_security also relies on Content-Length an if is not
> present, output buffering (and I suppose the limitation as well) stops
> (snip from apache2/apache2_io.c:output_filter):

No. If there's no C-L ModSecurity will count the bytes as they arrive.
If there are too many the entire response will be blocked with 500
(and the error page sent to the client).

>     case 0 :
>     /* We do not want to observe this response body
>      * but we need to remain attached to observe
>      * when it is completed so that we can run
>      * the RESPONSE_BODY phase.
>      */
>     msr->of_skipping = 1;
>     msr->resbody_status = RESBODY_STATUS_NOT_READ;
>     break;

The above happens when ModSecurity decides it is not interested in the
content (e.g. if it is an image, or some other opaque file).

>
>
> On 2/13/07, Nick Kew <nick@webthing.com> wrote:
> > On Mon, 12 Feb 2007 23:35:24 +0100
> > Henrik Nordstrom <henrik@henriknordstrom.net> wrote:
> >
> > > mån 2007-02-12 klockan 21:55 +0000 skrev Nick Kew:
> > >
> > > > Because the chunking filter is equipped to discard the chunk that
> > > > takes it over the limit, and substitute end-of-chunking.
> > > > If we do that in a new filter, we have to reinvent that wheel.
> > >
> > > Not sure substitue "end-of-chunking" is a reasonable thing here. It's
> > > an abort condition, not an EOF condition. Imho you'd better abort the
> > > flow, that way telling the client that the request failed instead of
> > > silently truncating the response.
> >
> > How would you abort it other than by truncating it?
> > Don't forget, the headers are long gone.
> >
> > If you don't send an end-marker, the client will
> > sit there waiting for more.
> >
> > --
> > Nick Kew
> >
> > Application Development with Apache - the Apache Modules Book
> > http://www.apachetutor.org/
> >
>
>
> --
> Dziugas
>


-- 
Ivan Ristic

Mime
View raw message