perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
Subject Re: [patch] C implementation of $r->content + rfc on the name
Date Sun, 18 May 2003 23:05:03 GMT
Geoffrey Young wrote:
> 
> 
> Stas Bekman wrote:
> 
>> I forgot to mention this URL, where Doug has stated why we shouldn't 
>> implement $r->content (and $r->args in list context), but to delegate 
>> it to CGI.pm, Apache::Request and other util modules.
>> http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=102182866024188&w=2
>>
>> I think there is no interest collisions here, as the new method simply 
>> returns the whole POSTed body as is and will be documented as such.
> 
> 
> I'm inclined to agree with doug, namely:
> 
> - if one wishes to simply read POST data, there is the more modern
>   {setup,should,get}_client_block api, and even more modern filter
>   api.  along with continued support for read(STDIN, ...) and
>   $r->read($buf, $r->headers_in->{'content-length'})
> 
> my preference is to stick to the Apache API as much as possible, so for 
> me I'd probably rather see the *client_block_api opened up or documented 
> (depending on its current status).  the alternative is to tell people to 
> use CGI.pm (which ships standard with perl, so it's not a big issue) 
> until libapreq officially supports mp2, or return to the old STDIN stuff 
> everyone used to do back in the old days :)
> 
> really, dropping $r->content is just a matter of education - it's not 
> like there aren't other ways to get POST data already (not that I've 
> tried ;)

Have you read the first sentence of my post:

recently I've learned that the implementation of ap_get_client_block is buggy.

What I've forgotten to mention that Justin suggests to deprecate and remove 
this API from 2.2.

We also need to rewrite all the code where it's used. Because currently 
mod_perl 2.0, using those methods, doesn't quite work when filters, returning 
EOS in the bb, are used.

Using the filter bucket brigade is the way to go, but it's slower doing that 
in perl. So the only suggestion I was making is doing it in C. CGI.pm's 
implementation is even slower, since it asks to read data in specified chunks, 
so everytime the chunk ends in the middle of bucket, you have to split buckets.

The suggested solution was to slurp the data faster (with performance 
improvements from gozer). The new $r->content won't be useful to most people 
anyways, because it doesn't parse the body. We could even extend it to use the 
POST limit feature and then CGI.pm could use it as well, instead of reading 
from STDIN. Resulting in faster CGI.pm.



__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Mime
View raw message