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?
On Wednesday 05 November 2003 02:00 pm, Stas Bekman wrote:
Lincoln Stein wrote:
OK, I've traced through stuff. The current proposed fix will break the ability to read and write CGI state to temporary files, database handles, etc when operating under mod_perl. Possibly some of the persistent state engines use this, but I think I'll leave it as a known bug.
May I suggest that this is a design bug? Why read_from_client would read from temp files and database handles? doesn't client always mean STDIN? So if you can keep read_from_client usage only to when you want to read from STDIN, than there is no problem. What do you think?
__________________________________________________________________ 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
--
__________________________________________________________________ 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