Re: [mp2] ModPerl-Registry/t/bad_scritps.t returns 403 not 500
Thank you Beau for a complete bug report. a. ModPerl-Registry/t/bad_scritps.t returns 403 not 500. bad_scripts1..1 # Running under perl version 5.008 for linux # Current time local: Thu Sep 4 16:19:34 2003 # Current time GMT: Fri Sep 5 02:19:34 2003 # Using Test.pm version 1.24 # testing : the script hasn't declared its private $r # Failed test 1 in bad_scripts.t at line 13 # expected: 500 # received: 403 not ok 1 c. Error log: [...] The error message is right there: [Thu Sep 04 16:19:34 2003] [error] file permissions deny server execution/usr/local/src/modperl2/modperl-2.0/ModPerl-Registry/t/cgi-bin/r_in herited.pl What perms do you get when you do: ls -l ModPerl-Registry/t/cgi-bin/r_inherited.pl it should be a+rx, e.g. on my machine it's: -rwxr-xr-x1 stas stas 248 Mar 7 19:58 I think when I have added this file to cvs it didn't have the +x bit, which I then have fixed directly in the cvs repository. I have just made a fresh checkout and the perms seem to be correct. May be you have an old checkout of this file, try to do: rm ModPerl-Registry/t/cgi-bin/r_inherited.pl cvs up ModPerl-Registry/t/cgi-bin/r_inherited.pl and try again. __ Stas BekmanJAm_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
Re: cookie managerment
On 5 Sep 2003, at 04:48, James.Q.L wrote: in mod_perl how do i detect if users choose to reject the cookie being sent to them and/or having the cookie disable in browser ? (not javascript or other client-side scripting) so that i can print a error message remind user to enable cookie. Here's a scheme that works for me: Set the cookie. Redirect them to a page that expects the cookie. In your handler, if you're visiting a page that expects the cookie you take one of two actions: - If the Referer was the page that's supposed to set the cookie, send them to the page telling them to turn on cookies. - Otherwise send them back to the page that sets the cookie (usually a login page). It's a simple scheme, and relies on Referer which everyone will now tell me is bad, but it does work. Matt. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] ModPerl-Registry/t/bad_scritps.t returns 403 not 500
- Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Beau E. Cox [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Thursday, September 04, 2003 9:09 PM Subject: Re: [mp2] ModPerl-Registry/t/bad_scritps.t returns 403 not 500 Thank you Beau for a complete bug report. a. ModPerl-Registry/t/bad_scritps.t returns 403 not 500. bad_scripts1..1 # Running under perl version 5.008 for linux # Current time local: Thu Sep 4 16:19:34 2003 # Current time GMT: Fri Sep 5 02:19:34 2003 # Using Test.pm version 1.24 # testing : the script hasn't declared its private $r # Failed test 1 in bad_scripts.t at line 13 # expected: 500 # received: 403 not ok 1 c. Error log: [...] The error message is right there: [Thu Sep 04 16:19:34 2003] [error] file permissions deny server execution/usr/local/src/modperl2/modperl-2.0/ModPerl-Registry/t/cgi-bin/r_in herited.pl What perms do you get when you do: ls -l ModPerl-Registry/t/cgi-bin/r_inherited.pl it should be a+rx, e.g. on my machine it's: -rwxr-xr-x1 stas stas 248 Mar 7 19:58 I think when I have added this file to cvs it didn't have the +x bit, which I then have fixed directly in the cvs repository. I have just made a fresh checkout and the perms seem to be correct. May be you have an old checkout of this file, try to do: rm ModPerl-Registry/t/cgi-bin/r_inherited.pl cvs up ModPerl-Registry/t/cgi-bin/r_inherited.pl and try again. Thanks Stas - Sorry I missed the error. I did the 'rm' and re-cvs'ed - flags correct and test OK. Next I rmeoved my entire source tree and re-cvs'ed. Flags on r_inherit... OK. Test OK. There are three scripts w/o execute permission: not_executable.pl (I guess that's correct) lib.pl local-conf.pl Aloha = Beau; == please visit == http://beaucox.com = main site http://howtos.beaucox.com = howtos http://PPM.beaucox.com = perl PPMs http://CPAN.beaucox.com = CPAN == thank you == -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: [mp2] ModPerl-Registry/t/bad_scritps.t returns 403 not 500
Beau E. Cox wrote: May be you have an old checkout of this file, try to do: rm ModPerl-Registry/t/cgi-bin/r_inherited.pl cvs up ModPerl-Registry/t/cgi-bin/r_inherited.pl and try again. Thanks Stas - Sorry I missed the error. I did the 'rm' and re-cvs'ed - flags correct and test OK. Next I rmeoved my entire source tree and re-cvs'ed. Flags on r_inherit... OK. Test OK. It's a drawback of cvs, which can't update perms if they have changed after checking out the file. One has to delete and re-check out the file. There are three scripts w/o execute permission: not_executable.pl (I guess that's correct) lib.pl local-conf.pl That's fine. So we are all set ;) __ Stas BekmanJAm_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
Re: [mp2] ModPerl-Registry/t/bad_scritps.t returns 403 not 500
Stas - Yep - ALL SET! Thanks a $1,000,000. Aloha = Beau; PS: I wonder whose anti-spam filter is going to junk this email? :) -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: ***SPAM 06.50 / 05.00 *** Re: [mp2] ModPerl-Registry/t/bad_scritps.t returns 403 not 500
Beau E. Cox wrote: SPAM: Start SpamAssassin results -- SPAM: This mail is probably spam. The original message has been altered SPAM: so you can recognise or block similar unwanted mail in future. SPAM: See http://spamassassin.org/tag/ for more details. SPAM: SPAM: Content analysis details: (6.5 hits, 5 required) SPAM: Hit! (2.7 points) BODY: Nigerian scam key phrase ($NN,NNN,NNN.NN) SPAM: Hit! (1.8 points) No MX records for the From: domain SPAM: Hit! (2.0 points) Received via a relay in relays.osirusoft.com SPAM:[RBL check: found 131.239.131.213.relays.osirusoft.com.] SPAM: SPAM: End of SpamAssassin results - Stas - Yep - ALL SET! Thanks a $1,000,000. Aloha = Beau; PS: I wonder whose anti-spam filter is going to junk this email? :) Mine ;-) Ernest -- ProgramV - Alice on Perl - available at http://www.virtualitas.net/perl/aiml/ VIRTUALITAS - Manufacturer of fine OOPPS - since 1996 * * VIRTUALITAS Inc. * http://www.virtualitas.net * * Ernest Lergon *mailto:[EMAIL PROTECTED] * * PGP-Fingerprint 6E6F DC17 A886 342D D63F 7880 12F5 6BA9 PGP-Key http://www.virtualitas.net/Ernest_Lergon.asc Member of the Alicebot and AIML Architecture Committee http://www.alicebot.org/committees/architecture.html - SPAM ALERT http://www.virtualitas.net/spam.html - -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Session and pnotes
On Tue, 2 Sep 2003 20:21:45 +0200 Xavier Noria [EMAIL PROTECTED] wrote: On Tuesday 02 September 2003 07:28, Perrin Harkins wrote: Sorry, I don't understand what you're saying here. What you should be doing is fetching the session once, putting it in pnotes, and getting it from pnotes for the rest of the request. I am sorry, I'll try to reword it. Let's assume a new user comes to the website. We set up a session for him and put the session id in a cookie to be sent in the response. As you know, somewhere in the request cycle of that particular request Apache::Session::Oracle stores the session in the database. When later that very user comes back to the website with a valid session id in the cookie, one reads the session from the database. The problem I am facing is that if the session is stored in pnotes() it doesn't end up in the database. When the user comes back that id corresponds to no row in the sessions table. Hi Xavier, If you want a transaparent session management you could also look Apache::SessionManager mod_perl extension. No extra code to write but a few lines to add in httpd.conf or .htaccess.file :-) by - Enrico -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Cookie Code
On Thu, 2003-09-04 at 16:56, Tim Edwards wrote: I'm sending 3 cookies. The first one goes properly. The second two get print to the screen. Same script run under normal perl works fine. Suggestions? Show us the mod_perl part of your apache config. - Perrin Running Apache 1.3.27 and mod_perl 1.26. The script I'm using is running in the CGI-BIN directory till I can spend time and pull out all the sub routine to put in seperate files then I'll move them to the PERL directory. IfDefine HAVE_PERL AddModule mod_perl.c /IfDefine Directory /var/www/cgi-bin SetHandler perl-script PerlHandler Apache::PerlRun AllowOverride None Options ExecCGI PerlSendHeader On Order allow,deny Allow from all /Directory Directory /var/www/perl SetHandler perl-script PerlHandler Apache::Registry Options +ExecCGI PerlSendHeader on /Directory _ Express yourself with MSN Messenger 6.0 -- download now! http://www.msnmessenger-download.com/tracking/reach_general -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: PATCH porting.pod First Mystery
Stas Bekman [EMAIL PROTECTED] writes: local is perl4-ism, nowadays it's used only for localizing special perl variables, like $|. Using package variables and local() in to do the job of block-scoped lexicals is a Perl4-ism. On the other hand, when using global variables (in which I include Perl's package variables and Perl's file-scoped lexicals) something with the semantics of local() is useful. It is, therefore, annoying that local cannot be used on lexical variables and even LW has said that this restriction is artifical and wrong. I agree that as a programming technique global variables are vulgar. However the First Mystery is all about porting CGI scripts that are already using global variables (implemented using file-scoped lexicals). It is the use of global variables in the first place that is vulgar, using local() does not make the code any more vulgar. Secongly it's a smaller change. Agreed, but it's not the proper change, your change can break code. Only in really obscure circumstances. Of course, if at the same time, you make an unrelated change that breaks the code I can see how you'd be tempted to blame me. :-) Assuming that we had: use warnings; my $counter = 0; print hit $counter times; Your change: use warnings; local our $counter; print hit $counter times; No, that's not my change, I said to change my to local our. I didn't say to remove initialization. Anyhow, local() does something quite different. It undefines it upon exit of the current scope. On the exit of the scope local() restores the previous value if any, and if none was assigned in first place (which implies undef) it's reset to undef. Yes, I know that. I don't think it has anything to do with finalization, it just looks like it does. Bluebells are not blue, they are actually pink and just look like they are blue :-) I use the term 'finalization' to (amongst other things) refer to declaring an action that is to take place when a given scope is removed from the execution stack. This is what 'local' does. The word, however, is not important as I don't propose to use it in the guide. However I'm not against your 'local our' solution, I'm just saying that it's less obvious than an explicit initialization, even though it requires more modification. Not-very advanced users will just get confused by this solution. Normally variables need to be initialized before they are used, so they will have to init them in any case and undef is not what they want. The porting guide assumes we start with a working CGI script. If a variable needs to be initialized to a value other than undef then a working script must already do so. For example we can provide an explicit initialization example The example in my modified porting.pod already shows explicit initialization: local our $counter = 0; after that suggest that you can say 'local our $foo' to globalize and localize it at the same time if you prefer to init those to undef via local(). Sounds like a good compromise to me. That fails to mention the real reason for using local. [ about use vars ] The guide is written to reduce the number of questions, not raise their number. Solution: mention both (our and use vars) How about we leave the example as I have it now and say: In this simple example, 'local' is redundant because $counter is explicitly initialized and never holds a reference. For variables that hold references (especially to objects interfacing to entities outside Perl) 'local' ensures timely destruction. For variables lacking explicit initialization 'local' also initializes them to undefined. The 'our' function appeared in 5.6, for backward compatability: use vars qw( $counter ); $counter = 0; We could also go on to talk about the option of explicitly initializing variables with undef() to save the minute overhead of using local() but I think that's unwarranted in porting.pod. Perhaps it should be covered in perl_reference.pod. [ file handle example ] I didn't suggest that particular use I realise that the simple file handle example was a poor choice to illustrate my point. Here's a better example that could form the basis of a more verbose explation in perl_reference.pod. Suppose you have: my $thing = Thing-new; Now suppose that Thing objects involve lots of resources (shared memory segments, temporary files, large Perl data structures, network connections various database/NNTP/SNPP/whatever servers and so on) and/or suppose that Thing objects perform some sort of output buffering and then flush it in Thing::DESTROY. If I change that to: our $thing = Thing-new; Then all of these resources are held until the script is next run or until the interpreter thread is killed. If I change it to: local our $thing = Thing-new; It does the right thing. You might think you could simply undef($thing)
Re: SubRequest in Filter MP2 [QUESTION]
Hello again.. On Thu, 2003-09-04 at 14:21, Geoffrey Young wrote: see Apache::SSI for mp1 - it does exactly what you are trying to do and is subclassable, so you can add your own tags/functionality if you want. That is exactly what I am already doing. When using #exec directive I noticed I could not set the headers properly. see recipe 5.7 in the mod_perl developer's cookbook for that, or look at the Apache::SSI source, which does it a different way. That is something i have yet to get my hands on! -- Craig Shelley [EMAIL PROTECTED] Homepage: http://www.microtron.org.uk -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Reply to List
Hi, Just wondering why the mailing list has sets the list-post: header to [EMAIL PROTECTED] This can be quite annoying since mail clients like evolution have a Reply to List option which saves a lot of fafing about. Since the list email address appears to be wrong Reply to List cannot be used. I have a natural habit of using this feature, and end up with bounce messages like: Hi. This is the qmail-send program at apache.org. I'm afraid I wasn't able to deliver your message to the following addresses. This is a permanent error; I've given up. Sorry it didn't work out. [EMAIL PROTECTED]: This list is now [EMAIL PROTECTED] Thanks. --- Below this line is a copy of the message. Maybe it has not been updated? -- Craig Shelley [EMAIL PROTECTED] Homepage: http://www.microtron.org.uk -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: SubRequest in Filter MP2 [QUESTION]
Craig Shelley wrote: Hello again.. On Thu, 2003-09-04 at 14:21, Geoffrey Young wrote: see Apache::SSI for mp1 - it does exactly what you are trying to do and is subclassable, so you can add your own tags/functionality if you want. That is exactly what I am already doing. When using #exec directive I noticed I could not set the headers properly. typically, a subrequest gets its headers from the current request. if you want to alter them, use $r-headers_in-set, but this is generally only used to test what-if scenarios: what if the current request had a cookie, could it access this document? anyway, if you need that, then you could probably create your own subclass and override ssi_exec to simply set the incoming headers and then SUPER::ssi_exec. or something like that (off the top of my head, anyway ;) see recipe 5.7 in the mod_perl developer's cookbook for that, or look at the Apache::SSI source, which does it a different way. That is something i have yet to get my hands on! the book has a simpler example as well, but you should be able to figure out the important LWP bits from the online code example http://www.modperlcookbook.org/code/ch05/Cookbook/SubRequestContent.pm --Geoff -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: $r-headers_out Location and Set-Cookie
On Wed, Sep 03, 2003 at 09:42:00, Garrett Goebel said...
And gives the following recipe:
Example A-3. redirect_cookie.pl
use Apache::Constants qw(REDIRECT OK);
my $r = shift;
# prepare the cookie in $cookie
$r-err_headers_out-add('Set-Cookie' = $cookie);
$r-headers_out-set(Location = $location);
$r-status(REDIRECT);
$r-send_http_header;
return OK;
How would you have written it?
Seems to me you'd want to *return* REDIRECT, not set $r-status to REDIRECT.
Here's what I do in this case:
$r-header_out(Location = $location);
return REDIRECT;
I don't know if it's 100% correct, but it works quite well for me.
I've also used $r-internal_redirect($location) for some things, but I don't
think that's appropriate here.
--
Michael Stella | Sr. Unix Engineer / Developer | http://www.thismetalsky.org
To dwell on the destination is to waste the journey
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: $r-headers_out Location and Set-Cookie
Michael wrote:
On Wed, Sep 03, 2003 at 09:42:00, Garrett Goebel said...
And gives the following recipe:
Example A-3. redirect_cookie.pl
use Apache::Constants qw(REDIRECT OK);
my $r = shift;
# prepare the cookie in $cookie
$r-err_headers_out-add('Set-Cookie' = $cookie);
$r-headers_out-set(Location = $location);
$r-status(REDIRECT);
$r-send_http_header;
return OK;
How would you have written it?
http://marc.theaimsgroup.com/?l=apache-modperlm=106260380606735w=2
thanks, I meant to put that in myself :)
Seems to me you'd want to *return* REDIRECT, not set $r-status to REDIRECT.
Here's what I do in this case:
$r-header_out(Location = $location);
return REDIRECT;
I don't know if it's 100% correct, but it works quite well for me.
actually, the return value is entirely ignored in Registry scripts - that's
why we need the $r-status hack, which is not needed (or desired) in
handlers. if you returned SERVER_ERROR it would still work, so long as you
set $r-status :)
however, yes, I prefer your way and return REDIRECT instead of OK - it just
seems to make things that much closer to handler behavior, as well as being
a bit more intuitive.
--Geoff
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Reply to List
Craig Shelley wrote: Hi, Just wondering why the mailing list has sets the list-post: header to [EMAIL PROTECTED] This can be quite annoying since mail clients like evolution have a Reply to List option which saves a lot of fafing about. Since the list email address appears to be wrong Reply to List cannot be used. [...] Maybe it has not been updated? Good catch, Craig. I have forwarded your request to the list owner (modperl-owner [EMAIL PROTECTED] perl.apache.org), where this kind of requests should be sent to. Watch the headers, I'm sure Ask will fix them asap. __ Stas BekmanJAm_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
Re: PATCH porting.pod First Mystery
Brian McCauley wrote: [...] OK, your last post's examples were more to the point of wanting to destroy objects at the end of the request, and hence here is a new summary: - move the perl4 lib solution to the perl_reference.pod - suggest turning a lexical variable declared with my() into a global variable declared with our() to avoid the closure, with the following buts: o if with my() it wasn't crucial to initialize the variables (since my() initialized them to 'undef'), now all variables declared with our() must be explicitly initialized. s/my $counter = 0/our $counter = 0/; [Brian: notice that I prefer *not* to suggest using local() to init vars, and rather have users do that explicitly, which is a good practice] o since the initialization of global variables happens at the beginning of the request, if a variable which contains an object: my $query = CGI-new; is made global: our $query = CGI-new; it won't be destroyed untill the next request. If you wish to make sure that it's destroyed at the end of the request, you must local()'ize the variable: local our $query = CGI-new; - users of perl 5.6 have to use 'use vars' instead of 'our'. So the above examples become: use vars qw($counter); $counter = 0; and: use vars qw($query); local $query = CGI-new; - point to perl_reference.pod for other workarounds/solutions. Please let me know if I have missed something from your last posts suggestions. __ Stas BekmanJAm_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
Apache on windows XP
Hello Everyone, I am getting the following error running Apache 1.3 on a windows XP machine. I was not able to find any message in the error.log Is this a problem only on windows XP will I be fine on windows 2000. Is there any way I can debug this issue. Any help is appreciated. Error: Apache has encountered a problem and needs to close szAppName: Apache.exe szAppVer: 0.0.0.0 szModName: ntdll.dll szModVer: 5.1.2600.1106 offset: 6a8d Thanks Niranjan
Re: Apache on windows XP
On Fri, 2003-09-05 at 13:17, Niranjan Patel wrote: I am getting the following error running Apache 1.3 on a windows XP machine. Are you running mod_perl? If so, how did you install it? If not, you need to ask your question on another list. The list for general apache user help can be found on the apache.org website. This list is for mod_perl users. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: Apache::Session and pnotes
Sorry, I missed this message until now... On Tue, 2003-09-02 at 14:21, Xavier Noria wrote: Let's assume a new user comes to the website. We set up a session for him and put the session id in a cookie to be sent in the response. As you know, somewhere in the request cycle of that particular request Apache::Session::Oracle stores the session in the database. It happens when the session object gets destroyed. The problem I am facing is that if the session is stored in pnotes() it doesn't end up in the database. When the user comes back that id corresponds to no row in the sessions table. Okay, the problem is not pnotes. The pnotes stuff gets cleared at the end of every request, so it would save then, after the user disconnects. Probably what's happening is that you have a scoping problem somewhere in your code that deals with pnotes and it is keeping the session object from going out of scope. One thing you can try is explicitly saving the session, using the method described in the Apache::Session documentation. If that works, it means you just have to find your scoping problem. Maybe you can locate it by removing code bit by bit until the problem goes away. If you can make a very short script that demonstrates the problem, you can post it here and we'll help you find it. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
[ANNOUNCE] HTTP-WebTest 2.04
The URL http://martynov.org/tgz/HTTP-WebTest-2.04.tar.gz has entered CPAN as file: $CPAN/authors/id/I/IL/ILYAM/HTTP-WebTest-2.04.tar.gz size: 90381 bytes md5: 16bfb8e76bf301e788241d774cab7cee NAME HTTP::WebTest - Testing static and dynamic web content DESCRIPTION This module runs tests on remote URLs containing Perl/JSP/HTML/JavaScript/etc. and generates a detailed test report. This module can be used as-is or its functionality can be extended using plugins. Plugins can define test types and provide additional report capabilities. This module comes with a set of default plugins but can be easily extended with third party plugins. CHANGES SINCE 2.03: BUG FIXES: * ReportPlugin.pm had a bug that it sended out email report even if mail parameter was set to errors and all tests passed. Thanks to Naoki Shima for a patch. -- Ilya Martynov, [EMAIL PROTECTED] CTO IPonWEB (UK) Ltd Quality Perl Programming and Unix Support UK managed @ offshore prices - http://www.iponweb.net Personal website - http://martynov.org -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: apache2, mod_perl: problem with CGI
Stas, Thanks that did it. It would be nice though if the minimum rev level of the CGI.pm could be mentioned in the doc. Or maybe it is there somewhere and I skimmed over it. The 'Configuring mod_perl2.0 page for win32' at http://perl.apache.org/docs/2.0/os/win32/config.html would a nice place to mention this. Kind Regards Bart -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED] Sent: Friday, September 05, 2003 1:20 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: apache2, mod_perl: problem with CGI Just trying to get up and running with Apache/2.0.47 (Win32) mod_perl/1.99_10-dev Perl/v5.8.0 Server Have installed AS Perl 5.8 and the mod_perl ppm that Randy provides the world with. Running my mod_perl code using the ModPerl::Registry handler. Now everything is fine until I put the following in my code: use CGI(); my $q = CGI-new(); From that point on I get a servererror and the following entry in the apache logfile: [Fri Sep 05 00:17:12 2003] [error] 1688: ModPerl::Registry: Can't locate object method request via package Apache at C:/Perl/lib/CGI.pm line 269. upgrade your CGI.pm to 2.93 or higher. __ Stas BekmanJAm_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
RE: porting from mod_perl1 to mod_perl2
Hi, I have an application running under apache 1.37(win32)/mod_perl1.27_01-dev/perl5.6 build 633 I am trying to move this application to apache 2.0.47(win32)/mod_perl1.99_10-dev/perl 5.8 However I run into a problem with character encoding. Somewhere in this app I put up a form that contains text. The encoding of the html page that contains this form is set to 'utf-8' by the following: meta http-equiv=content-type content=text/html; charset=UTF-8 / That form displays OK in both mod_perl1.0 and mod_perl2.0 When I read the form back under the apache1, everything is OK. When I do the same using the apache 2 combination I run into trouble with the char ref entities entities which are high in the unicode set like: #8212; or #8211;. These characters are returned as unicode characters hex 97 and hex 96. Other character ref entities like the one for e (e umlaut = #235;) are returned correctly. So I assume that only characters above 07FFF are returned wrong. Anybody any idea? Thanks in advance Bart PS: some might say that this has nothing to do with mod_perl. And maybe you are right, but I have no clue which part might be causing this. I am fairly sure it is not perl5.8. Although in order to make the apache2/mod_perl2 combination to work I had to upgrade the CGI.pm to version 3.0 -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: porting from mod_perl1 to mod_perl2
Hi there, On Sat, 6 Sep 2003, Bart Terryn wrote: Hi, I have an application running under apache 1.37(win32)/mod_perl1.27_01-dev/perl5.6 build 633 I am trying to move this application to apache 2.0.47(win32)/mod_perl1.99_10-dev/perl 5.8 However I run into a problem with character encoding. Have you checked perldoc perllocale ? 73, Ged. -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
RE: porting from mod_perl1 to mod_perl2
On Fri, 2003-09-05 at 19:14, Bart Terryn wrote: PS: some might say that this has nothing to do with mod_perl I would say that, but it's okay, you didn't know. I am fairly sure it is not perl5.8. I'm fairly sure it is. What is your locale set to? Are you on Red Hat? See previous discussions of locale issues on Red Hat 8 and 9 in the list archives. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: apache2, mod_perl: problem with CGI
Thanks that did it. Great. It would be nice though if the minimum rev level of the CGI.pm could be mentioned in the doc. Or maybe it is there somewhere and I skimmed over it. It's a a CGI.pm problem, really. We can't go and support all possible modules that may or may not run under mod_perl 2.0. However we do have this section: http://perl.apache.org/products/apache-modules.html#Porting_CPAN_modules_to_mod_perl_2_0_Status We probably should specify the version number of each of these modules. Can somebody please lookup those modules and send me a patch with the version number which starts to support mod_perl 2.0? No need for Apache::Peek, CGI and CGI::Cookie since I know these versions already. I'm CC'ing Shannon, since he has ported most of the auth modules. The 'Configuring mod_perl2.0 page for win32' at http://perl.apache.org/docs/2.0/os/win32/config.html would a nice place to mention this. Certainly not there, since it's windows specific and CGI.pm is used on all platforms. However we could link to the URL I have mentioned from other docs. I think porting docs are more relevant, than config. [Fri Sep 05 00:17:12 2003] [error] 1688: ModPerl::Registry: Can't locate object method request via package Apache at C:/Perl/lib/CGI.pm line 269. upgrade your CGI.pm to 2.93 or higher. __ Stas BekmanJAm_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
Re: porting from mod_perl1 to mod_perl2
Perrin Harkins wrote: I am fairly sure it is not perl5.8. I'm fairly sure it is. What is your locale set to? Are you on Red Hat? See previous discussions of locale issues on Red Hat 8 and 9 in the list archives. Bart is on win32, AS Perl 5.8. I doubt it's a locale issue, since it's the client who decides what encoding the data is in, it's either CGI.pm (guessing that what he was using to parse the forms) or more low level (io) issues. Bart, can you test whether you have the same problem when a run the same code under mod_cgi in Apache2 (with perl5.8 ofcourse)? If not, that will point the blaming finger towards mod_perl 2.0. Someone volunteers to add a new test? See t/modperl/print_utf8.t t/response/TestModperl/print_utf8.pm for an example of testing the responding with utf8 data. You can probably adopt one of these couples for testing the posting of utf8 data: t/apache/cgihandler.t t/response/TestApache/cgihandler.pm t/modules/cgi.t t/response/TestModules/cgi.pm t/modules/cgiupload.t t/response/TestModules/cgiupload.pm of course you will want to create a new couple of files for this test. __ Stas BekmanJAm_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
Re: porting from mod_perl1 to mod_perl2
On Fri, 2003-09-05 at 21:36, Stas Bekman wrote: Bart is on win32, AS Perl 5.8. Oops, sorry Bart, I missed that. Even so, I'm suspicious that 5.8 and all of its unicode changes are involved somehow. - Perrin -- Reporting bugs: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html
Re: apache2, mod_perl: problem with CGI
I'll disagree on this being a windows only problem in CGI. I'll also
disagree about the version number.
As late as CGI 3.00 this problem exists in Apache 1.3.27 and mod_perl
1.27 on SunOS.
The pdf troubleshooting doc on apache.org site suggest fix (I think its
5.17) also does _not_ work either
a temp work around I've come up with is
eval {
$query = CGI-new();
};
return 1 if $@;
instead of just
$query = CGI-new();
Stas Bekman wrote:
Thanks that did it.
Great.
It would be nice though if the minimum rev level of the CGI.pm could be
mentioned in the doc.
Or maybe it is there somewhere and I skimmed over it.
It's a a CGI.pm problem, really. We can't go and support all possible
modules that may or may not run under mod_perl 2.0. However we do have
this section:
http://perl.apache.org/products/apache-modules.html#Porting_CPAN_modules_to_mod_perl_2_0_Status
We probably should specify the version number of each of these
modules. Can somebody please lookup those modules and send me a patch
with the version number which starts to support mod_perl 2.0?
No need for Apache::Peek, CGI and CGI::Cookie since I know these
versions already.
I'm CC'ing Shannon, since he has ported most of the auth modules.
The 'Configuring mod_perl2.0 page for win32' at
http://perl.apache.org/docs/2.0/os/win32/config.html would a nice
place to
mention this.
Certainly not there, since it's windows specific and CGI.pm is used on
all platforms. However we could link to the URL I have mentioned from
other docs. I think porting docs are more relevant, than config.
[Fri Sep 05 00:17:12 2003] [error] 1688: ModPerl::Registry: Can't
locate
object method request via package Apache at C:/Perl/lib/CGI.pm
line
269.
upgrade your CGI.pm to 2.93 or higher.
__
Stas BekmanJAm_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
