perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Philippe M. Chiasson" <>
Subject Re: [patch] C implementation of $r->content + rfc on the name
Date Tue, 20 May 2003 06:33:04 GMT
On Tue, 2003-05-20 at 06:55, Stas Bekman wrote:
> Philippe M. Chiasson wrote:
> > I would many times over prefer users to use something similar to
> > should_client_block(). But if enough users of mp _want_ to have
> > $r->content, we need a _good_ way of achieving that (or a better excuse
> > not to do it: "nevermind that, just use libapreq2 and it'll be even
> > simpler/faster")
> Phillippe, let me repeat again: get_client_block API is broken (See the recent 
> thread on httpd-dev), and rumours go that it may be deprecated and totally 
> removed. So the suggested $r->content is really a replacement for 
> get_client_block that works.

I meant something similar to get_client_block et all. I know what busted
state that API is ;-)

I just meant that for that kind of data pulled from the client, I would
prefer if we kept a way for the user to read that data in chunks,
instead as in a whole buffer.

If I understand how Joe explained the mechanism of libapreq2, it's
exactly what I mean.

If you have 10Mb of POST data coming in, there is no reason why your
process should grow of that amount, if you are never interested in more
than a specific chunk, like the value of one header or another.

> __________________________________________________________________
> Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
>     mod_perl Guide --->
-- -----------------------------------------------------------------------------
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5 (122FF51B/C634E37B)    F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3 A5A5
Q: It is impossible to make anything foolproof because fools are so ingenious.
perl -e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/&&print||$$++&&redo}'

View raw message