perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: [patch] C implementation of $r->content + rfc on the name
Date Tue, 20 May 2003 06:43:35 GMT
Philippe M. Chiasson wrote:
> 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
>>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.

Sure, agreed. Let's see if get_client_block get fixed in the httpd-core, if 
not we will simply write our own the right way. Still we may have to deal with 
older httpd versions.

Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker     mod_perl Guide --->

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message