Lincoln Stein wrote:
No, it made sense for the fastCGI and original Apache::Request modules. The CGI state data potentially comes from many sources: sometimes from
stdin and sometimes from mod_perl.
That part is clear, and we are good here. But you said something different. You said that read_from_client is also used to read from filehandles and database handles. How could that be the case under mod_perl? mod_perl always reads from the client socket (which is either disguised as STDIN or accessed via internal Apache APIs). Can you give me an example of when read_from_client running under mod_perl will suddenly decide to read from a filehandle which is not STDIN or a database handle?
> $q = CGI->new(\*FH);
Perfect. Thanks. So the solution is simple. Raise a flag if a custom filehandle was supplied and always use it to read the data from, otherwise use the current solution. Does it sound like a good solution?
So the logic will look like:
- return read($fh, $$buff, $len, $offset); + return $MOD_PERL && !$self->custom_fh + ? $self->r->read($$buff, $len, $offset) + : read($fh, $$buff, $len, $offset);
Do you want me to come up with a new patch against the version you just have sent in?
__________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
-- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
