Sending a different protocol header
I've done a fair amount of searching and still can not find an answer to this. I'm writing a mod_perl2 handler and would like to output my own headers. Specifically I'd like to output headers like this: - ICY 200 OK icy-notice1: some info icy-name: some info icy-url: some info Content-Length: length SOME CONTENT - When trying to output these headers it doesn't work and just becomes part of the content. If I remove the ICY 200 OK line, the rest of the headers work just fine. I'd like to override the HTTP/1.1 headers. How can this be done? I also tried changing the ICY line above to Status: ICY 200 OK, and the server ended up outputing, HTTP/1.1 ICY 200 OK I've read the documentation and posts about PerlOptions +ParsedHeaders, etc. but nothing has pointed me to a way to completely control the headers that are being sent out. Please help! -HANS
[MP2] Strange slow MySQL queries
I run a site with a few million MySQL requests a day, but I've run into a strange problem which I'm trying to slove. The server is running Apache 2.0.47, mod_perl2-1.99r09, DBI 1.38 and DBD-mysql 2.1026 on a FreeBSD 4.8 machine. About once or twice a day, I get a bunch of slow queries that doesn't look like they should be slow. And most of the day they aren't. Examples: # Query_time: 51 Lock_time: 0 Rows_sent: 0 Rows_examined: 0 update innodb_tbl set col1=col1-1000, col2=col2-1000, col3=col3-1000 where primary_key=50; # Query_time: 46 Lock_time: 0 Rows_sent: 0 Rows_examined: 0 update innodb_tbl set col4=1 where primary_key=50; # Query_time: 11 Lock_time: 0 Rows_sent: 1 Rows_examined: 0 select * from innodb_tbl where primary_key=1 for update; . The list goes on and on... All of my slow queries are really fast at all other times. Fast as in instant. This doesn't look like a load issue, and I'm having problems figuring out what is causing this. Any ideas where to start digging and what I should try doing? I really need this solved. Regards, Erlend Simonsen
Re: Sending a different protocol header
Hans wrote: I've done a fair amount of searching and still can not find an answer to this. I'm writing a mod_perl2 handler and would like to output my own headers. Specifically I'd like to output headers like this: - ICY 200 OK icy-notice1: some info icy-name: some info icy-url: some info Content-Length: length SOME CONTENT - When trying to output these headers it doesn't work and just becomes part of the content. If I remove the ICY 200 OK line, the rest of the headers work just fine. I'd like to override the HTTP/1.1 headers. How can this be done? try setting $r-assbackwards(1) before returning your response. this should supress the apache headers and allow only your own to get through, provided you print them instead of putting them in the headers_out table. btw, can you please explain what ICY is for me? the $r-assbackwards(1) thing was specifically implemented in mod_perl 1.0 to support ICY, and I used it in examples I give of this, but I always have to say that I have no idea what ICY is. thanks --Geoff
Re: [MP2] Strange slow MySQL queries
Hi, This looks more like a MySQL problem than a specific MP2 issue. However here are a couple of pointers. All the queries below are updates on the same table this would indicate to me you may be having a locking issue. What you need to do is locate the locking transaction it may be as simple as :- select * from innodb_tbl for update; This locks the whole table and would block all of the quiries highlighted. Hope it helps Paddy P.S. Please feel free to contact me off list if you wish to go into more depth. Are you using Apache::DBI or transactions? On Mon, Sep 08, 2003 at 01:13:31PM +0200, Erlend Simonsen wrote: I run a site with a few million MySQL requests a day, but I've run into a strange problem which I'm trying to slove. The server is running Apache 2.0.47, mod_perl2-1.99r09, DBI 1.38 and DBD-mysql 2.1026 on a FreeBSD 4.8 machine. About once or twice a day, I get a bunch of slow queries that doesn't look like they should be slow. And most of the day they aren't. Examples: # Query_time: 51 Lock_time: 0 Rows_sent: 0 Rows_examined: 0 update innodb_tbl set col1=col1-1000, col2=col2-1000, col3=col3-1000 where primary_key=50; # Query_time: 46 Lock_time: 0 Rows_sent: 0 Rows_examined: 0 update innodb_tbl set col4=1 where primary_key=50; # Query_time: 11 Lock_time: 0 Rows_sent: 1 Rows_examined: 0 select * from innodb_tbl where primary_key=1 for update; . The list goes on and on... All of my slow queries are really fast at all other times. Fast as in instant. This doesn't look like a load issue, and I'm having problems figuring out what is causing this. Any ideas where to start digging and what I should try doing? I really need this solved. Regards, Erlend Simonsen
[ANNOUNCE] OpenInteract 1.99_03 (2.0 beta 3) released
The third beta of OpenInteract2 (1.99_03) has been released to CPAN and Sourceforge. (Release 1.99_02 was skipped for consistency.) This release includes: * Many documentation updates, including a full package development tutorial * Actions can store messages to be passed from the controller to the view, which combined with a decent templating system makes it a piece of cake to have error-aware input fields * API for management tasks has been modified to make adding tasks easier * Lots more tests (like anyone cares...) * Tons of assorted improvements and fixes throughout the system. A detailed changelog is online [1] as are the HTML-ified docs.[2] And if you can't wait for your CPAN mirror you can download it immediately.[3] Thanks, Chris [1]http://openinteract.sourceforge.net/docs/oi2/OpenInteract2/Manual/Changes.shtml [2]http://openinteract.sourceforge.net/docs/oi2/ [3]http://prdownloads.sourceforge.net/openinteract/OpenInteract-1.99_03.tar.gz?download -- Chris Winters ([EMAIL PROTECTED]) Building enterprise-capable snack solutions since 1988.
Help wanted with locations / configuration
Hi, I'm having trouble deciding what the best plan is for the arrangement of the components of a new project that I'm starting. The project is going to be written as a series of mod_perl handlers - one for the main home page, and others for various sub-components. Each handler is implemented by a separate module (all sub-classes of a common base class). I don't want to have to configure a separate Location for each sub-component. It also needs to have access to various static resources (images, stylesheets, JavaScript libraries etc.). Thus, I want to have something like this: /myproject [mp1] /myproject/component1 [mp1] /myproject/component2 [mp1] ... /myproject/images [static] /myproject/javascript [static] /myproject/stylesheets [static] The question is: What is the best way to configure this? So far I've come up with two options: OPTION 1. Specify a /myproject Location with dispatcher method as the mod_perl handler; then specify a LocationMatch for the images, javascript and stylesheets that overrides the /myproject Location: Location /myproject SetHandler perl-script PerlHandler MyProject-dispatcher /Location LocationMatch ^/myproject/(images|javascript|stylesheets) SetHandler default-handler /LocationMatch The dispatcher method there looks at the URI requested and either returns DECLINED (or 404?) if it doesn't recognise it, or else loads the appropriate MyProject sub-class and then runs the real content generation routine in that (i.e. a routine like I would have specified as the handler for that URI if I had configured a separate Location for each component). This seems to have a minor problem in practice -- if I request a directory, rather than a file, in one of the static locations (e.g. /myproject/images or /myproject/images/) then the dispatcher method gets called! The LocationMatch override only seems to work if I request a file (e.g. /myproject/images/piccy1.jpg). Thus, I need to put some extra code into the dispatcher to repeat the pattern match for the static locations, and change the handler to the default-handler and return DECLINED if it has received such a URI. OPTION 2. Specify a /myproject Location with a PerlFixupHandler that behaves very much like the dispatcher above, except that it actually sets the handler to PerlHandler and assigns the appropriate callback method (i.e. the content generation routine in the component sub-class) when it spots a recognised component URI; otherwise it just returns DECLINED, leaving the request to be handled by the default-handler: Location /myproject PerlFixupHandler MyProject-fixup /Location (Am I correct in thinking that I don't need to specify SetHandler: perl-script for a PerlFixupHandler? That's only for the main PerlHandler response handler, isn't it?) Does either of these options have any benefit over the other? Are there other better ways to do it? Thanks in advance, - Steve
ANNOUNCE: Mason 1.23
1.23 [ ENHANCEMENTS ] - Lots of enhancements to the Apache.pm emulation when using the CGIHandler module. Implemented by David Wheeler. - The fact that autohandlers or dhandlers can be turned off by setting autohandler_name or dhandler_name to has now been documented, and we explicitly check for this in the code. Task id #499. - The ApacheHandler module now catches exceptions thrown from the Interp class's make_request method. With the default Mason Interp Request classes, this will never happen. However, subclasses may want to throw exceptions when constructing a request. Implemented by David Wheeler. [ BUG FIXES ] - If any code type parameters were set in the httpd.conf file, Mason died trying to read them. This bug was introduced in version 1.20. Task id #496. Reported by David Wheeler. - $m-caller, $m-callers and $m-caller_args now return undef or an empty list instead of crashing when the specified stack level does not exist. Task id #495. Reported by Bernhard Schmalhofer. - The busy_lock option to $m-cache-get did not accept did not accept string values for durations, like 4m. Task id #484. Reported by Igor Muratov. - When generating the HTML error message page, we now only use basic HTML escaping. This fixes two problems. One is that if HTML::Entities is not installed, using the |h escape flag in the error display component causes an endless loop. The other is that the |h flag can mangle non-Latin-1 characters. Task ids #497 and #494. Reported by Harmen and Oleg Bartunov respectively. - If a component generated output, then called another component via $m-scomp, and that other component attempted to clear the buffer and then abort, any output generated before the call to $m-scomp was still sent to the client. This broke calling $m-redirect inside an $m-scomp call. Task id #498. Reported by Kim Alexander Hansen. -- Forwarded message -- Date: Mon, 8 Sep 2003 18:45:01 +0200 From: PAUSE [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: Dave Rolsky [EMAIL PROTECTED] Subject: CPAN Upload: D/DR/DROLSKY/HTML-Mason-1.23.tar.gz The uploaded file HTML-Mason-1.23.tar.gz has entered CPAN as file: $CPAN/authors/id/D/DR/DROLSKY/HTML-Mason-1.23.tar.gz size: 326918 bytes md5: b1029cc9dce53d5a9a58275e24f96625 No action is required on your part Request entered by: DROLSKY (Dave Rolsky) Request entered on: Mon, 08 Sep 2003 16:43:12 GMT Request completed: Mon, 08 Sep 2003 16:45:01 GMT Thanks, -- paused, v441
Re: Help wanted with locations / configuration
On Mon, 2003-09-08 at 11:51, Steve Hay wrote:
It also needs to have access to various static resources (images,
stylesheets, JavaScript libraries etc.).
Thus, I want to have something like this:
/myproject [mp1]
/myproject/component1 [mp1]
/myproject/component2 [mp1]
...
/myproject/images [static]
/myproject/javascript [static]
/myproject/stylesheets [static]
You might want to look at having a translation handler.
We're doing something similar to this, where images and javascripts live
under the same directory structure as the handler is managing. Instead
of trying to configure this via that httpd.conf file, we chose to have a
translation handler look at the incoming uri and determine whether the
request is for a static file or for the code.
Inside of our transhandler we're doing this:
sub handler
{
my $r=shift;
my $uri=$r-uri;
my $Tmplpath=/our/static/files/rootdir/;
if (($uri !~ /jpg$/) ($uri !~ /css$/) ($uri !~ /js$/))
{
$r-notes('host' = $Host);
$r-notes('olduri' = $uri);
$r-uri(/);
return DECLINED;
}
else
{
my $File=$Tmplpath . $uri;
$r-filename($File);
return OK;
}
}
If a request is made for anything ending in .jpg, .js or .css, we tell
apache where to find the file by appending the uri (/images/the.jpg for
example) to a path. The handler then returns OK, which tells apache not
to try to figure out where the file lives on its own, and returns the
file to the browser.
Any other request is passed to the handler, along with a field in
notes() that shows what we were asking for in the first place. Our
request handler uses this to dispatch the request to the correct object
needed to fulfill the request. (Our handler is configured at /, so we
override the uri passed from the browser to /).
Any other types you want can be added to this, I just threw the ones
that seemed relevant to you. I hope this helps.
Marc Slagle
Whapps LLC
Re: Help wanted with locations / configuration
Hi!
On Mon, Sep 08, 2003 at 04:51:55PM +0100, Steve Hay wrote:
The project is going to be written as a series of mod_perl handlers -
one for the main home page, and others for various sub-components.
Each handler is implemented by a separate module (all sub-classes of a
common base class). I don't want to have to configure a separate
Location for each sub-component.
You might want to take a look at Apache::Dispatch, which does exactly this.
Location /myproject
SetHandler perl-script
PerlHandler MyProject-dispatcher
/Location
LocationMatch ^/myproject/(images|javascript|stylesheets)
SetHandler default-handler
/LocationMatch
I'm using something like this with Apache::Dispatch
PerlModule Apache::Dispatch
DispatchUpperCase On # this is /not/ in Apache::Dispatch,
# only in my patched version
DispatchPrefix Oe1
DispatchExtras Error
Location /myproject
SetHandler perl-script
PerlHandler Apache::Dispatch
/Location
Location /myproject/css
SetHandler default
/Location
Location /myproject/img
SetHandler default
/Location
This is working as expected, i.e. request for /css/foo.css or /img/bar.png
are not handled by Apache::Dispatch
--
#!/usr/bin/perl http://domm.zsi.at
for(ref bless{},just'another'perl'hacker){s-:+-$-gprint$_.$/}
Re: Sending a different protocol header
assbackwards works. Thanks! When I first read your response about a method called assbackwards I thought it was sarcasm :) understandable :) actually, the assbackwards slot of the request record is there to indicate that the incoming request used HTTP/0.9, which defines only GET and where no headers are expected in the response. so, for HTTP/0.9 requests r-assbackwards is 1, otherwise it is 0. apache internally hacks r-assbackwards on various occasions where headers should be supressed in the response, such as with a subrequest. mod_perl also hacks the assbackwards flag to suit its needs. in mod_perl 1.0 $r-assbackwards did not exist (except in various XS extensions created solely for educational purposes :) but one of the cool things about mod_perl 2.0 is that the entire API is opened up (finally :) ICY is for IceCast, a protocol for sending meta information about music streams. cool, thanks. --Geoff
Re: Help wanted with locations / configuration
Steve Hay [EMAIL PROTECTED] wrote It also needs to have access to various static resources (images, stylesheets, JavaScript libraries etc.). Thus, I want to have something like this: /myproject [mp1] /myproject/component1 [mp1] /myproject/component2 [mp1] ... /myproject/images [static] /myproject/javascript [static] /myproject/stylesheets [static] Location /myproject SetHandler perl-script PerlHandler MyProject-dispatcher /Location LocationMatch ^/myproject/(images|javascript|stylesheets) SetHandler default-handler /LocationMatch Correct me if I'm wrong, but can't you just say Location /myproject Location /myproject AddHandler perl-script .cgi PerlHandler MyProject-dispatcher /Location using AddHandler instead of SetHandler. This will not override the default handler for things like images/stylesheets/static html. This way you don't need the LocationMatch ^/myproject/(images|javascript|stylesheets) ... tags. Michael Peters Venzia
Re: Sending a different protocol header
On Mon, 2003-09-08 at 13:12, Geoffrey Young wrote: actually, the assbackwards slot of the request record is there to indicate that the incoming request used HTTP/0.9, which defines only GET and where no headers are expected in the response. Clearly this works, but wouldn't it be better to implement a protocol handler for IceCast instead? Or is that just overkill for this? - Perrin
Re: Sending a different protocol header
Perrin Harkins wrote: On Mon, 2003-09-08 at 13:12, Geoffrey Young wrote: actually, the assbackwards slot of the request record is there to indicate that the incoming request used HTTP/0.9, which defines only GET and where no headers are expected in the response. Clearly this works, but wouldn't it be better to implement a protocol handler for IceCast instead? Or is that just overkill for this? I dunno. that IceCast is a protocol seems to make it a perfect candidate for a protocol handler. however, since I have yet to play with that aspect of apache or mod_perl, I don't know the overhead involved, especially if an ICY request is the same as an HTTP request, and supressing headers is the only difference between HTTP and ICY responses. but yes, hans, for the record Apache 2.0 and mod_perl 2.0 both support the idea of protocol handlers, if you're interested. see http://perl.apache.org/docs/2.0/user/handlers/protocols.html --Geoff
Re: Help wanted with locations / configuration
On Mon, 2003-09-08 at 11:51, Steve Hay wrote: Thus, I want to have something like this: /myproject [mp1] /myproject/component1 [mp1] /myproject/component2 [mp1] ... /myproject/images [static] /myproject/javascript [static] /myproject/stylesheets [static] The question is: What is the best way to configure this? Others have already given good advice, but I would add that your URLs and your filesystem don't need to be tied tightly together. You could just alias the static files to somewhere else: Alias /static/images /myproject/images Then you can simply refer to them in URLs as /static/images/foo.jpg. Alternatively, you could use a Location setting for your dispatcher that has nothing to do with your files: Location /wild/and/crazy/path/for/handlers SetHandler perl-script PerlHandler MyProject-dispatcher /Location Then you can call /wild/and/crazy/path/for/handlers/component1 and it will work as long as your dispatcher is smart enough to ignore the beginning path. (Apache::Dispatch is.) - Perrin
Re:[OT] Sending a different protocol header
btw, can you please explain what ICY is for me? the $r-assbackwards(1) thing was specifically implemented in mod_perl 1.0 to support ICY, and I used it in examples I give of this, but I always have to say that I have no idea what ICY is. IceCast. The LINUX version of WinAmp's streaming MP3 server. Issac
'die' in a CleanupHandler
Just curious ... what happens if I call 'die' in a mod_perl handler (especially a CleanupHandler)? Does it actually kill the apache child or does something catch the exception before that happens? -- Ray Zimmerman / e-mail: [EMAIL PROTECTED] / 428-B Phillips Hall Sr Research / phone: (607) 255-9645 / Cornell University Associate / FAX: (815) 377-3932 / Ithaca, NY 14853
Re: Cookie Code
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? Just a suggestion, but are you sure that you don't print out the content-type header after sending the first cookie ? It somehow sounds like you do ...
Re: 'die' in a CleanupHandler
On Mon, 2003-09-08 at 16:10, Ray Zimmerman wrote: Just curious ... what happens if I call 'die' in a mod_perl handler (especially a CleanupHandler)? Does it actually kill the apache child or does something catch the exception before that happens? The latter. Your 'die' is caught by mod_perl. Is there something you're trying to do? - Perrin
Re: Sending a different protocol header
Geoffrey Young wrote: Perrin Harkins wrote: On Mon, 2003-09-08 at 13:12, Geoffrey Young wrote: actually, the assbackwards slot of the request record is there to indicate that the incoming request used HTTP/0.9, which defines only GET and where no headers are expected in the response. Clearly this works, but wouldn't it be better to implement a protocol handler for IceCast instead? Or is that just overkill for this? [...] but yes, hans, for the record Apache 2.0 and mod_perl 2.0 both support the idea of protocol handlers, if you're interested. see http://perl.apache.org/docs/2.0/user/handlers/protocols.html And an example of how to extend HTTP protocol, without inventing a new one (this example extends HTTP to support invented by me EMAIL protocol): http://perl.apache.org/docs/2.0/user/handlers/http.html#PerlHeaderParserHandler __ 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
Re: Content encoding when filtering proxyed pages
Esteban Fernandez Stafford wrote:
Hello all,
I have a machine acting as a proxy using mod_perl-1.99_09 with apache
2.0.46. This proxy is supposed to filter all html content. So far I
have achieved most of my project's goals. But there is one issue I
can't get straight, this is when the proxy gets a page that is
encoded (like in www.google.com). My first attempt was to DECLINE
filtering such pages, but the $filter-r()-content_encoding() always
gives me 'undef'. Is this something that is not yet implemented or am
I doing something wrong? (See code below) Then I tried looking at
$filter-r()-headers_out()-{'Content-Encoding'} and everything went
just fine!
Looks like it's autogenerated, but probably not working, as I see that the
corresponding call in the test is commented out:
t/response/TestAPI/request_rec.pm:#content_encoding
Need to check why is it so.
On the other hand, is it possible that I could put mod_deflate before
my filter to get the content already decompressed for my filter to
parse?
Sure, you can do that. the mp2 test suite has examples of how to do that
(besides the normal apache docs).
Thanks a lot in advance
I would like to thank the mod_perl community for mod_perl, it has made
the development of this project fun! And it has kept me from having to
go back to C programming. It was a long time since I last did that.
thanks for the kind words ;)
__
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
Re: CPAN module Apache::Emulator
Adam Kennedy wrote: For those interested, I've been doing a general clean up of the code ( shrinking the code size down mainly ), prior to starting further work on it. Code available on request. My intentions is to keep it as light as possible. While Apache::Fake seems to be able to do a very large amount of things, including reading Apache config files by the look of it, I'll be trying to keep this to some minimum set of features. Enough to provide all the standard functionality, but not to do any fancy tricks. One of the ideas was to have a more intuitive namespace for Apache emulators. The suggestion was to introduce a new namespace ApacheEmu:: or similar. So yours will be ApacheEmu::Request and David's Apache::Table emulator, will be ApacheEmu::Table, etc. The logic is that all these modules do not require Apache to run and therefore shouldn't be in the Apache:: namespace. Adam Nigel Wetters wrote: David Wheeler [EMAIL PROTECTED] 09/03/03 05:46am May I suggest that you post a note to the modperl list announcing Apache::Emulator. I think that the folks there might be interested in your work. A couple of years ago, I produced a module that emulated a few of the Apache::Request methods from a CGI environment. The only reason for doing this was that I was writing an adserver (boo hiss) that I wanted to run on both Apache and Netscape webservers, but didn't want to write code in CGI. I released the code to CPAN as Apache::Emulator within a rarely used Adserver distribution. My code wasn't complete, or by any means pleasant, but, I guess it was a good idea because Jorg Walter finished off the job with his excellent, and comprehensive Apache::Fake distrubution. Recently, Adam Kennedy has expressed an interest in adding a few methods to Apache::Emulator, and I dusted off the distribution for him (separating the code from the Adserver I'd written). I think he would like to have Apache::Emulator be a slimmed down version of Apache::Fake, keeping only the most popular features. I'm glad that somepone has taken an interest. I think this repackaging is what raised the interest of a few mod_perl developers. However, at the moment, there is nothing new here. Nigel [EMAIL PROTECTED] -- __ 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
Re: 'die' in a CleanupHandler
At 6:19 PM -0400 9/8/03, Perrin Harkins wrote: On Mon, 2003-09-08 at 16:10, Ray Zimmerman wrote: Just curious ... what happens if I call 'die' in a mod_perl handler (especially a CleanupHandler)? Does it actually kill the apache child or does something catch the exception before that happens? The latter. Your 'die' is caught by mod_perl. Is there something you're trying to do? I was just considering how to handle it when a serious error occurs during a CleanupHandler and was wondering what the difference was between 'warn' and 'die' in that context. -- Ray Zimmerman / e-mail: [EMAIL PROTECTED] / 428-B Phillips Hall Sr Research / phone: (607) 255-9645 / Cornell University Associate / FAX: (815) 377-3932 / Ithaca, NY 14853
Re: apache2, mod_perl: problem with CGI
Stas Wrote:
I believe it's not the problem Bart was talking about. You are most
likely talking about Apache-request failing, which is how it should be
if the GlobalRequest option is not set. Bart's problem was finding
the request method.
If you'll read carefully, you'll see that I'm talking about mod_perl 1.x
not mod_perl 2.
Otherwise, I would completely agree. The _exact_ same code _does_ work
under mod_perl2.
I also see that the problem Bart was referring to was fixed in 2.93
Philip M. Gollucci wrote:
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
Re: apache2, mod_perl: problem with CGI
Philip M. Gollucci wrote:
Stas Wrote:
I believe it's not the problem Bart was talking about. You are most
likely talking about Apache-request failing, which is how it should be
if the GlobalRequest option is not set. Bart's problem was finding
the request method.
If you'll read carefully, you'll see that I'm talking about mod_perl 1.x
not mod_perl 2.
Otherwise, I would completely agree. The _exact_ same code _does_ work
under mod_perl2.
Ah, sorry, so what exact problem you are talking about? Can you post a link to
the HTML version of the relevant section in the guide, I'm not sure what 5.17 is?
I also see that the problem Bart was referring to was fixed in 2.93
Philip M. Gollucci wrote:
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 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
