Return-Path: Delivered-To: apmail-perl-dev-archive@perl.apache.org Received: (qmail 92051 invoked by uid 500); 13 Jun 2003 07:05:31 -0000 Mailing-List: contact dev-help@perl.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Delivered-To: mailing list dev@perl.apache.org Received: (qmail 92023 invoked from network); 13 Jun 2003 07:05:31 -0000 Received: from erato.logilune.com (HELO mail.logilune.com) (195.154.174.52) by daedalus.apache.org with SMTP; 13 Jun 2003 07:05:31 -0000 Received: from stason.org (localhost.logilune.com [127.0.0.1]) by mail.logilune.com (Postfix) with ESMTP id ACE7C79A23; Fri, 13 Jun 2003 09:05:37 +0200 (CEST) Message-ID: <3EE977B0.8000107@stason.org> Date: Fri, 13 Jun 2003 17:05:20 +1000 From: Stas Bekman Organization: Hope, Humanized User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joe Schaefer , dev@perl.apache.org Subject: Re: CGI.pm not processing POST within AuthenHandler References: <3EE3F9B3.6080203@october29.net> <3EE96B25.7020008@stason.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N [moving this discussion to the dev list. it's very important] Joe Schaefer wrote: > Stas Bekman writes: > > >>[offlist] >> >>Joe Schaefer wrote: >> >> >>>>Apache/2.0.44 (Gentoo/Linux) mod_perl/1.99_09 Perl/v5.8.0 CGI.pm/2.93 >>> >>>Attempting to read POST data before the content-handler is called >>>is unsafe with httpd-2. You'll probably have to wait for >>>Apache::Request to be ported over in order to do something like that. >> >>Why do you say that it's unsafe? > > > > I haven't looked at how CGI.pm implements this, but IIRC the problem > with reading POST data from an auth handler is that ap_run_insert_filter > doesn't get called until the content handler is invoked. If there > are any request filters that are supposed to be active for the > request, they'll be missed by CGI.pm 's parse. Good point. We need to document this and make sure that CGI.pm does the right thing. Either it needs to check some flag that is available only inside the response handler or use the API that checks which phase we are in, which I haven't committed yet. However what should do those who want to devise their own custom auth handlers, not based on mechanisms provided by Apache, but using HTML forms? Perhaps we need a technique to call ap_run_insert_filter(r) early if there is a need for that? Of course developers will have to be aware of the risks. I guess if CGI.pm and Apache::Request do the right thing, then they shouldn't worry about it. > mod_apreq.c still doesn't handle this situation quite right, but > I have a good idea about how it should be fixed. mod_cache.c runs it manually: modules/experimental/mod_cache.c: ap_run_insert_filter(r); however it has an excuse of being run as quick handler hook __________________________________________________________________ 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