Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (herse.apache.org: domain of dziugas@gmail.com designates
 64.233.182.186 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=PG64ZS23l88d83fA5mshi/kxRlbIOCEWRBcVgcdQHu6c4V0/bNfzLQx2YYCDl2DZC3edtudgoF3PRcLyEmCaXKceZylC+WRe756iSs0aJMNWQkAND0ONzEwHix8OMMvAKmDY8U7zVO/QK1J1oCxTeD0fD1NTeniGgMFumMs0z0g=
Message-ID: <943470880702130315w7db51b4r75a8ef943d8964f9@mail.gmail.com>
Date: Tue, 13 Feb 2007 13:15:01 +0200
From: "Dziugas Baltrunas" <dziugas@gmail.com>
To: dev@httpd.apache.org
Subject: Re: Limiting response body length
In-Reply-To: <20070212230912.30d8d900@grimnir>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <943470880702120241n6e9fe716v6457ee09e81ae040@mail.gmail.com>
	 <45D0A35E.6080704@sanguis.xs4all.nl> <20070212175142.25d21156@grimnir>
	 <1171314597.23049.69.camel@henriknordstrom.net>
	 <20070212215523.22dfc553@grimnir>
	 <1171319724.23049.149.camel@henriknordstrom.net>
	 <20070212230912.30d8d900@grimnir>

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):

    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 =3D 1;
    msr->resbody_status =3D RESBODY_STATUS_NOT_READ;
    break;


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=E5n 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/
>


--=20
Dziugas