Is there any other alternative
Hi, We are using following in the middle of the mod_perl scripts, Can some one state are there any side effects or mis URL handling with use of these functions parsed_uri;unparse() , we are on apache 2.2 with mod_perl what are the alternatives or is it alright to keep the following my $uri_parsed = $r-parsed_uri; my $unparsed = $uri_parsed-unparse(); $unparsed =~ s/\???ticket=[^]+//; As this is this is code in a authentication handler, can this produce malfunction URL, The mod_perl Authentication handler just populate the remote user only. pls do clarify -- View this message in context: http://www.nabble.com/Is-there-any-other-alternative-tp16671480p16671480.html Sent from the mod_perl - General mailing list archive at Nabble.com.
Re: [RELEASE CANDIDATE] mod_perl-2.0.4 RC1
Philippe M. Chiasson wrote: The mod_perl 2.0.4 release candidate 1 Works with Perl 5.10 is ready. It can be downloaded here: http://www.apache.org/~gozer/mp2/mod_perl-2.0.4-rc1.tar.gz All tests pass on: 1) Leopard, perl 5.8.8, httpd 2.2.4 2) Linux 2.6, perl 5.8.8, httpd 2.2.6 +1 Thanks for the great work on this Gozer! MD5: 1f0a941e8b5f26b6102126ae67ddbb43 SHA1: 8b2ceede3c783b9b2cc9e0fe63a095b0e4a1f000 Please give it a spin in your favorite configuration and report any problems. Especially needed against Perl-5.10 on Windows. The summary of what has changed since 2.0.3 are (from Changes): Fix $r-location corruption under certain conditions [Gozer] Fix a crash when spawning Perl threads under Perl 5.10 [Gozer] Fix erratic behaviour when filters were used with Perl 5.10 [Gozer] Fix problems with redefinitions of perl_free as free and perl_malloc as malloc on Win32, as described at http://marc.info/?l=apache-modperlm=119896407510526w=2 [Tom Donovan] Fix a crash when running a sub-request from within a filter where mod_perl was not the content handler. [Gozer] Refactor tests to use keepalives instead of same_interp [Gozer, Phred] Apache2::Reload has been moved to an externally maintained CPAN distribution [Fred Moyer [EMAIL PROTECTED]] PerlCleanupHandler are now registered with a subpool of $r-pool, instead of $r-pool itself, ensuring they run _before_ any other $r-pool cleanups [Torsten Foertsch] Fix a bug that would prevent pnotes from being cleaned up properly at the end of the request [Torsten Foertsch] On Win32, embed the manifest file, if present, in mod_perl.so, so as to work with VC 8 [Steve Hay, Randy Kobes] Expose apr_thread_rwlock_t with the APR::ThreadRWLock module [Torsten Foertsch] Don't waste an extra interpreter anymore under threaded MPMs when using a modperl handler [Torsten Foertsch] Fix a bug that could cause a crash when using $r-push_handlers() multiple times for a phase that has no configured handlers [Torsten Foertsch] Catch up with some httpd API changes 2.2.4: The full server version information is now included in the error log at startup as well as server status reports, irrespective of the setting of the ServerTokens directive. ap_get_server_version() is now deprecated, and is replaced by ap_get_server_banner() and ap_get_server_description(). [Jeff Trawick] 2.3.0: ap_get_server_version() has been removed. Third-party modules must now use ap_get_server_banner() or ap_get_server_description(). [Gozer] fixed Apache2::compat Apache2::ServerUtil::server_root() resolution issues [Joshua Hoblitt] *) SECURITY: CVE-2007-1349 (cve.mitre.org) fix unescaped variable interprolation in regular expression [Randal L. Schwartz [EMAIL PROTECTED], Fred Moyer [EMAIL PROTECTED]] Make $r-the_request() writeable [Fred Moyer [EMAIL PROTECTED]] fix ModPerl::RegistryCooker::read_script to handle all possible errors, previously there was a case where Apache2::Const::OK was returned on an error. [Eivind Eklund [EMAIL PROTECTED]] a minor compilation warning resolved in modperl_handler_new_from_sv [Stas] a minor compilation warning resolved in modperl_gtop_size_string [Stas] Prevent direct use of _deprecated_ Apache2::ReadConfig in Perl sections with httpd Alias directives from incorrectly generating 'The Alias directive in x at line y will probably never match' messages. [Philip M. Gollucci [EMAIL PROTECTED]] Prevent Apache2::PerSections::symdump() from returning invalid httpd.conf snippets like 'Alias undef' [Philip M. Gollucci [EMAIL PROTECTED]] Require B-Size 0.9 for Apache2::Status which fixes Can't call method script_name on an undefined value [Philip M. Gollucci [EMAIL PROTECTED]] -march=pentium4 or anything with an = in it in CCFLAGS or @ARGV that gets passed to xs/APR/APR/Makefile.PL broke the @ARGV parsing. I.E. FreeBSD port builds when users had CPUTYPE set in /etc/make.conf. [Philip M. Gollucci [EMAIL PROTECTED]] Fixes to get bleed-ithread (5.9.5+) to comile again. [Philip M. Gollucci [EMAIL PROTECTED]] -- Red Hot Penguin Consulting LLC http://www.redhotpenguin.com/
Handing over the POST input to a virtual included part?
Hi, is it possible to hand over the POST input of a SSI document to a virtual included part of it? I have an SSI document that contains !--#include virtual=/ptest/ptest.pl?$QUERY_STRING -- This way I can pass parameters that are passed in the URI to the subrequest. But how can that be done if the request method is POST? (There is only one such part that wants to read the input.) Thanks, Torsten
Re: Handing over the POST input to a virtual included part?
I think that virtual includes are handled with Apache sub-requests, so you might be able to get it the post data through $r-prev. Worth a shot anyway. Adam Quoting Torsten Foertsch [EMAIL PROTECTED]: Hi, is it possible to hand over the POST input of a SSI document to a virtual included part of it? I have an SSI document that contains !--#include virtual=/ptest/ptest.pl?$QUERY_STRING -- This way I can pass parameters that are passed in the URI to the subrequest. But how can that be done if the request method is POST? (There is only one such part that wants to read the input.) Thanks, Torsten
Re: Handing over the POST input to a virtual included part?
Torsten Foertsch wrote: Hi, is it possible to hand over the POST input of a SSI document to a virtual included part of it? I have an SSI document that contains !--#include virtual=/ptest/ptest.pl?$QUERY_STRING -- This way I can pass parameters that are passed in the URI to the subrequest. But how can that be done if the request method is POST? (There is only one such part that wants to read the input.) convert the POST to a GET? there are docs on the site on how to do this. --Geoff
Re: Handing over the POST input to a virtual included part?
On Mon 14 Apr 2008, Geoffrey Young wrote: is it possible to hand over the POST input of a SSI document to a virtual included part of it? I have an SSI document that contains !--#include virtual=/ptest/ptest.pl?$QUERY_STRING -- This way I can pass parameters that are passed in the URI to the subrequest. But how can that be done if the request method is POST? (There is only one such part that wants to read the input.) convert the POST to a GET? there are docs on the site on how to do this. Thanks, that is at least a starting point to think. But I don't know how large the request body can become. So, I thought of something like read and cache the request body in something like fixup of the main request and then insert an input filter in the subrequest. The point is the subrequest goes through mod_proxy to another server. How do I insert an input filter in the filter chain of a subrequest? A subrequest is created with an output filter chain but nothing for input. Torsten -- Need professional mod_perl support? Just ask me: [EMAIL PROTECTED]
Template::Toolkit and mod_perl2?
I'm trying to do some basic conversions to an old site that uses TT, and attempting to get it running under mod_perl2. at the moment I'm getting no errors but the web pages aren't displaying. Before I get into too much detail, I'm just wondering if TT work under mod_perl2. Anyone have any experience with it? Got it running perhaps? Thx, Kirk
Re: Template::Toolkit and mod_perl2?
On Mon, Apr 14, 2008 at 7:29 AM, Kirk [EMAIL PROTECTED] wrote: I'm trying to do some basic conversions to an old site that uses TT, and attempting to get it running under mod_perl2. at the moment I'm getting no errors but the web pages aren't displaying. Before I get into too much detail, I'm just wondering if TT work under mod_perl2. Anyone have any experience with it? Got it running perhaps? Works fine. Check your return types and your headers. Post a simple example that's not working if you can. Thx, Kirk -- ~Tyler
Re: Handing over the POST input to a virtual included part?
On Mon, Apr 14, 2008 at 1:22 PM, Torsten Foertsch [EMAIL PROTECTED] wrote: Thanks, that is at least a starting point to think. But I don't know how large the request body can become. So, I thought of something like read and cache the request body in something like fixup of the main request and then insert an input filter in the subrequest. The point is the subrequest goes through mod_proxy to another server. At that point it's so complex that I think the value of using SSI is lost. I'd replace SSI with a local handler (or output filter) that does the POST to the other server the way you want it. - Perrin
Re: Template::Toolkit and mod_perl2?
This is a guess, but are you running under SetHandler modperl, and then trying to print $your_page. If that's the case, either use $r-print(), or change to SetHandler perl-script. Adam Quoting Kirk [EMAIL PROTECTED]: I'm trying to do some basic conversions to an old site that uses TT, and attempting to get it running under mod_perl2. at the moment I'm getting no errors but the web pages aren't displaying. Before I get into too much detail, I'm just wondering if TT work under mod_perl2. Anyone have any experience with it? Got it running perhaps? Thx, Kirk
RE: Template::Toolkit and mod_perl2?
[error] Can't locate object method preload via package Template::Config at /usr/lib/perl5/site_perl/5.8.8/Templat e.pm line 44. I'm using the test script right out of the TT: http://template-toolkit.org/docs/tutorial/Web.html#section_Dynamic_Content_G eneration_Via_CGI_Script with this in my conf file: Alias /soap-cgi/ /var/www/domain/soap-cgi/ Location /soap-cgi SetHandler perl-script PerlResponseHandler ModPerl::Registry Options +ExecCGI /Location From my CPAN install of TT: Template is up to date (2.19). Template::Config is up to date (2.74). And I'n running Fedora Core6, from apache log file: [notice] Apache/2.2.6 (Unix) DAV/2 PHP/5.1.6 mod_python/3.2.8 Python/2.4.3 mod_ssl/2.2.3 OpenSSL/0.9.8b mod_apreq2-20 051231/2.6.0 mod_perl/2.0.2 Perl/v5.8.8 configured -- resuming normal operations Kirk -Original Message- From: Tyler Gee [mailto:[EMAIL PROTECTED] Sent: Monday, April 14, 2008 10:33 AM To: [EMAIL PROTECTED] Cc: modperl@perl.apache.org Subject: Re: Template::Toolkit and mod_perl2? On Mon, Apr 14, 2008 at 7:29 AM, Kirk [EMAIL PROTECTED] wrote: I'm trying to do some basic conversions to an old site that uses TT, and attempting to get it running under mod_perl2. at the moment I'm getting no errors but the web pages aren't displaying. Before I get into too much detail, I'm just wondering if TT work under mod_perl2. Anyone have any experience with it? Got it running perhaps? Works fine. Check your return types and your headers. Post a simple example that's not working if you can. Thx, Kirk -- ~Tyler
Re: Handing over the POST input to a virtual included part?
is it possible to hand over the POST input of a SSI document to a virtual included part of it? I have an SSI document that contains !--#include virtual=/ptest/ptest.pl?$QUERY_STRING -- This way I can pass parameters that are passed in the URI to the subrequest. But how can that be done if the request method is POST? (There is only one such part that wants to read the input.) Isn't that information available via $r-main (perhaps the main request should go through a handler that stores the data somewhere, ie. pnotes). Kind regards, Frank
Removing an output filter handler from the filters chain
Hello,
I have a perl output filter handler that processes the title element of html
documents, after I am done with processing title element, I want to remove
the output filter handler from the output filters chain so that we do not
process the remaining bucket brigades to improve performance. Here is the
fragment of the script
...
if ($ctx-{done})
{ #ctx-{done} is true - we are done parsing the title, remove the handler from
the filter chain
$f-remove;
return Apache::Const::DECLINED;
}
…
It appears that the handler is not removed from the filter chain, the incoming
bucket brigades are still being processed by the filter.
Here is my environment
Red Hat Enterprise Linux
Apache/2.0.46
perl, v5.8.0
I would appreciate your help.
Thanks a lot.
Woinshet
Be a better friend, newshound, and
know-it-all with Yahoo! Mobile. Try it now.
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
