Return-Path: 
 <apreq-dev-return-434-apmail-httpd-apreq-dev-archive=httpd.apache.org@httpd.apache.org>
Delivered-To: apmail-httpd-apreq-dev-archive@httpd.apache.org
Received: (qmail 95624 invoked by uid 500); 26 Aug 2002 14:23:38 -0000
Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:apreq-dev@httpd.apache.org>
List-Help: <mailto:apreq-dev-help@httpd.apache.org>
List-Unsubscribe: <mailto:apreq-dev-unsubscribe@httpd.apache.org>
List-Subscribe: <mailto:apreq-dev-subscribe@httpd.apache.org>
Delivered-To: mailing list apreq-dev@httpd.apache.org
Received: (qmail 95611 invoked from network); 26 Aug 2002 14:23:37 -0000
Message-ID: <00e701c24d0c$2c6e07f0$1a0aa8c0@deepthought>
From: "Issac Goldstand" <margol@beamartyr.net>
To: "Stas Bekman" <stas@stason.org>,
        "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Cc: "Joe Schaefer" <joe@sunstarsys.com>,
        "apreq list" <apreq-dev@httpd.apache.org>
References: <Stas Bekman's message of "Sun,
 25 Aug 2002 12:11:00 +0800"> <Stas Bekman's message of "Fri,
 23 Aug 2002 00:36:32 +0800"> <m33ct8f3oe.fsf@mumonkan.sunstarsys.com>
 <200208212349.40583.chatgris@mediapow.com>
 <m3it23edez.fsf@mumonkan.sunstarsys.com> <3D647453.7030704@stason.org>
 <m3bs7vdjum.fsf@mumonkan.sunstarsys.com> <3D651310.3050008@stason.org>
 <5.1.0.14.2.20020822123542.02919dc8@pop3.rowe-clan.net>
 <m3n0red9g4.fsf@mumonkan.sunstarsys.com> <3D65AF9D.7060908@stason.org>
 <m3znveb2ld.fsf@mumonkan.sunstarsys.com> <3D65CA9A.4050706@stason.org>
 <m3sn16aywo.fsf@mumonkan.sunstarsys.com>
 <5.1.0.14.2.20020823035453.02bf93b8@pop3.rowe-clan.net>
 <3D6602E1.9070600@stason.org> <m3y9aw7ldj.fsf@mumonkan.sunstarsys.com>
 <036301c24bbb$59f45eb0$1a0aa8c0@deepthought>
 <m3n0rb7prc.fsf@mumonkan.sunstarsys.com> <3D6858D4.3090606@stason.org>
 <5.1.0.14.2.20020825004053.031dae98@pop3.rowe-clan.net>
 <3D69D03D.1050107@stason.org>
Subject: Re: dev question: apreq 2 as a filter?
Date: Mon, 26 Aug 2002 17:23:37 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N


----- Original Message -----
From: "Stas Bekman" <stas@stason.org>
To: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
Cc: "Joe Schaefer" <joe@sunstarsys.com>; "apreq list"
<apreq-dev@httpd.apache.org>
Sent: Monday, August 26, 2002 9:52 AM
Subject: Re: dev question: apreq 2 as a filter?


> William A. Rowe, Jr. wrote:
> > At 11:38 PM 8/24/2002, Joe Schaefer wrote:
>
> >> I'd rather the apreq filter behaved like a block-buffered filter would.
> >> AFAICT mod_deflate doesn't consume the whole body before passing it
> >> along,  so why do you think we need to?
> >
> >
> > No, we don't need the whole body.  The idea of pre-fetching 8kb, 16kb or
> > even 64kb is so that the variables are know up-front.  If someone needs
> > more, they simply need to call ap_get_brigade again until they have the
> > content they need.  And then it's their job to set aside the content for
> > the
> > next upstream filter or the final handler destination.
>
> What happens if you have a form with big input values, so that (e.g.)
> the last key/value won't feet into 8/16/64k. So when you call
> $r->params() (which is supposed to return all keys) you won't be able to
> get them all, meaning that you really have to suck the whole data in,
> before you know whether you have all the keys or not.

This is true, but it's a limitation of the content-type of the POSTed data,
not of HTTP or apreq.

  Issac