perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoffrey Young <ge...@modperlcookbook.org>
Subject Re: [patch] C implementation of $r->content + rfc on the name
Date Fri, 16 May 2003 12:05:32 GMT


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

--Geoff


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


Mime
View raw message