ANNOUNCE: Krang RSS 1.00
We're pleased to announce that Krang RSS v1.00 has been released. Krang RSS is a Krang element-library addon that creates RSS files for the purposes of syndication. RSS is designed to be easily integrated into existing Krang element libraries with minimal work. From the documentation: "The RSS element library addon to Krang is designed to generate RSS files for your website. Creating and publishing an RSS story at the root category of your site will result in an RSS 2.0 file of the 5 most-recently-published stories on the site." Download Krang RSS addon from the Krang add-on repository on the Krang website: http://krang.sourceforge.net/ - the Krang Team -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
mod_perl2 and document_root
Hey folks, I'm trying to learn how to use mod_perl to change document_root on
the fly, but I'm having a lot of difficulty with it. Here's the setup:
Apache/2.0.50, mod_perl/1.99_11 Perl/v5.8.4 PHP/4.3.8 Server
I'm calling the code this way:
PerlTransHandler MyApache::RewriteURI
...and this is what RewriteURI looks like (yes, wholly ripped off from the
documentation...):
###
package MyApache::RewriteURI;
use strict;
use warnings;
use Apache::RequestRec;
use Apache::RequestUtil;
use Apache::Const -compile => qw(DECLINED);
sub handler {
my $r = shift;
$r->document_root("/home/ddellacosta/web_dev/stuff/htdocs");
warn "DOCUMENT_ROOT = " . $r->document_root() . "\n";
$r->uri("forgot.phtml");
return Apache::DECLINED;
}
1;
###
When I try to run this, I get an Internal Server Error and this message in the
error_log:
Usage: Apache::RequestRec::document_root(r) at
/usr/lib/apache2/lib/perl/MyApache/RewriteURI.pm line 14.\n
Floating around on the web are dozens of examples of being able to set
document_root the way I'm trying to set it. However, I cannot seem to get this
to work. Am I doing something ridiculously obviously wrong? I am a mod_perl
newbie.
Thanks for any help!
Dave D.
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: write results of subrequest to file
Geoffrey Young wrote: Perrin Harkins wrote: On Fri, 2004-08-13 at 11:06, Geoffrey Young wrote: you can't do that with mod_perl 1.0 - you can $sub->run() but that result goes right to the client. For comparison, how would you do this in mp2? With a filter? pretty much. I believe that subrequests in apache2 have the same limitations as before wrt calling run(). but if the main reason you want to capture a subrequest is to post-process dynamic content then you can simply insert an output filter to do that for you, as that is what they were designed for. Nah, you can do it in a much cleaner way in mp2. See http://perl.apache.org/docs/2.0/api/Apache/SubRequest.html#C_lookup_uri_, but basically you can my $data; my $subr = $r->lookup_uri($uri, $filter); $subr->run; And $filter can be a very simple output filter that just stashes data as it comes out or anything else you feel like doing. --Geoff -- Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5 http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5 signature.asc Description: OpenPGP digital signature
Re: write results of subrequest to file
Philippe M. Chiasson wrote: Geoffrey Young wrote: Perrin Harkins wrote: On Fri, 2004-08-13 at 11:06, Geoffrey Young wrote: you can't do that with mod_perl 1.0 - you can $sub->run() but that result goes right to the client. For comparison, how would you do this in mp2? With a filter? pretty much. I believe that subrequests in apache2 have the same limitations as before wrt calling run(). but if the main reason you want to capture a subrequest is to post-process dynamic content then you can simply insert an output filter to do that for you, as that is what they were designed for. Nah, you can do it in a much cleaner way in mp2. See http://perl.apache.org/docs/2.0/api/Apache/SubRequest.html#C_lookup_uri_, but basically you can my $data; my $subr = $r->lookup_uri($uri, $filter); $subr->run; And $filter can be a very simple output filter that just stashes data as it comes out or anything else you feel like doing. Hmm, and where do you get this $filter object from? Do you have a working example? -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
How to close a socket when all you have in an Apache::Connection object
I'm writing a protocol handler for mod_perl 2.0. If all I have is an Apache::Connection object, how can I tell Apache I want to close the connection? I tried sending an end of stream bucket down the bucket brigade, but that clearly did nothing. What's the canonical solution? Regards, Ken -- MailChannels: Control Your Email http://www.mailchannels.com Ken Simpson, CEO +1-604-729-1741 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: How to close a socket when all you have in an Apache::Connection object
Ken Simpson wrote: I'm writing a protocol handler for mod_perl 2.0. If all I have is an Apache::Connection object, how can I tell Apache I want to close the connection? I tried sending an end of stream bucket down the bucket brigade, but that clearly did nothing. What's the canonical solution? Normally you quit the handler returning OK and the connection is getting closed by Apache. If that doesn't work for you, please show us a short code sample of what you are trying to achieve. Besides you have the client socket object, so may be you could do: $c->client_socket->close; -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl2 and document_root
Dave Della Costa wrote:
Hey folks, I'm trying to learn how to use mod_perl to change document_root on
the fly, but I'm having a lot of difficulty with it. Here's the setup:
Apache/2.0.50, mod_perl/1.99_11 Perl/v5.8.4 PHP/4.3.8 Server
I'm calling the code this way:
PerlTransHandler MyApache::RewriteURI
...and this is what RewriteURI looks like (yes, wholly ripped off from the
documentation...):
###
package MyApache::RewriteURI;
use strict;
use warnings;
use Apache::RequestRec;
use Apache::RequestUtil;
use Apache::Const -compile => qw(DECLINED);
sub handler {
my $r = shift;
$r->document_root("/home/ddellacosta/web_dev/stuff/htdocs");
warn "DOCUMENT_ROOT = " . $r->document_root() . "\n";
$r->uri("forgot.phtml");
return Apache::DECLINED;
}
1;
###
When I try to run this, I get an Internal Server Error and this message in the
error_log:
Usage: Apache::RequestRec::document_root(r) at
/usr/lib/apache2/lib/perl/MyApache/RewriteURI.pm line 14.\n
Floating around on the web are dozens of examples of being able to set
document_root the way I'm trying to set it. However, I cannot seem to get this
to work. Am I doing something ridiculously obviously wrong? I am a mod_perl
newbie.
Right. The examples you've found are from mod_perl 1, Apache2 has this in
its docs:
/**
* Retrieve the document root for this server
* @param r The current request
* @warning Don't use this! If your request went through a Userdir, or
* something like that, it'll screw you. But it's back-compatible...
* @return The document root
* @deffunc const char *ap_document_root(request_rec *r)
*/
AP_DECLARE(const char *) ap_document_root(request_rec *r);
we haven't had a chance yet to work on figuring out how to solve it for
mp2. Let me do some research and I'll be back to you shortly.
--
__
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
--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html
How to tell if there's data waiting on a NON-blocking Apache connection?
Oops -- the subject line was wrong last time. Let's try again: If all I have is an Apache::Connection object, is there a way to tell whether data is available from the connection's socket in the case where the connection has been put into nonblocking mode. Thanks, Ken -- MailChannels: Control Your Email http://www.mailchannels.com Ken Simpson, CEO +1-604-729-1741 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: write results of subrequest to file
Stas Bekman wrote: Philippe M. Chiasson wrote: Geoffrey Young wrote: Perrin Harkins wrote: On Fri, 2004-08-13 at 11:06, Geoffrey Young wrote: you can't do that with mod_perl 1.0 - you can $sub->run() but that result goes right to the client. For comparison, how would you do this in mp2? With a filter? pretty much. I believe that subrequests in apache2 have the same limitations as before wrt calling run(). but if the main reason you want to capture a subrequest is to post-process dynamic content then you can simply insert an output filter to do that for you, as that is what they were designed for. Nah, you can do it in a much cleaner way in mp2. See http://perl.apache.org/docs/2.0/api/Apache/SubRequest.html#C_lookup_uri_, but basically you can my $data; my $subr = $r->lookup_uri($uri, $filter); $subr->run; And $filter can be a very simple output filter that just stashes data as it comes out or anything else you feel like doing. Hmm, and where do you get this $filter object from? Do you have a working example? Hmm, I think you just got me there. I didn't think long enough before answering that one ;-) I can see why one can't do that now that I've looked at code for a few minutes, and sorry for misleading anybody on this one. -- Philippe M. Chiasson m/gozer\@(apache|cpan|ectoplasm)\.org/ GPG KeyID : 88C3A5A5 http://gozer.ectoplasm.org/ F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3A5A5 signature.asc Description: OpenPGP digital signature
Re: How to tell if there's data waiting on a NON-blocking Apache connection?
Ken Simpson wrote: Oops -- the subject line was wrong last time. Let's try again: If all I have is an Apache::Connection object, is there a way to tell whether data is available from the connection's socket in the case where the connection has been put into nonblocking mode. $c->client_socket gives you the socket object, now I suppose you want to poll() it for read. Unfortunately we haven't exposed APR::Poll yet. Take a look at the C API: http://lxr.webperf.org/source.cgi/srclib/apr/include/apr_poll.h http://docx.webperf.org/apr__poll_8h.html http://docx.webperf.org/group__apr__poll.html Is that what you are after? -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: write results of subrequest to file
Philippe M. Chiasson wrote: Stas Bekman wrote: Philippe M. Chiasson wrote: Geoffrey Young wrote: Perrin Harkins wrote: On Fri, 2004-08-13 at 11:06, Geoffrey Young wrote: you can't do that with mod_perl 1.0 - you can $sub->run() but that result goes right to the client. For comparison, how would you do this in mp2? With a filter? pretty much. I believe that subrequests in apache2 have the same limitations as before wrt calling run(). but if the main reason you want to capture a subrequest is to post-process dynamic content then you can simply insert an output filter to do that for you, as that is what they were designed for. Nah, you can do it in a much cleaner way in mp2. See http://perl.apache.org/docs/2.0/api/Apache/SubRequest.html#C_lookup_uri_, but basically you can my $data; my $subr = $r->lookup_uri($uri, $filter); $subr->run; And $filter can be a very simple output filter that just stashes data as it comes out or anything else you feel like doing. Hmm, and where do you get this $filter object from? Do you have a working example? Hmm, I think you just got me there. I didn't think long enough before answering that one ;-) I can see why one can't do that now that I've looked at code for a few minutes, and sorry for misleading anybody on this one. Ah, no, I think it's quite do-able, I just thought that you had an example at hand. The $filter argument is just a pointer to somewhere in the filter chain. So I suppose on could add a filter for the subrequest and pass $filter: $subr->output_filters. But as I don't have a test, I can't vouch for it to work. If you want I can write a test for it later, but now I need to resolve if a few other issues first. So let me know if you want me to work on this. -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: How to tell if there's data waiting on a NON-blocking Apache connection?
> $c->client_socket gives you the socket object, now I suppose you want to > poll() it for read. Unfortunately we haven't exposed APR::Poll yet. Take a > look at the C API: > > http://lxr.webperf.org/source.cgi/srclib/apr/include/apr_poll.h > http://docx.webperf.org/apr__poll_8h.html > http://docx.webperf.org/group__apr__poll.html > > Is that what you are after? Yes, this is exactly what we need. Ideally, the APR interface should support the operations supported by IO::Select -- but it appears to. How much work is it to write the mappings for APR::Poll? I've never done it before but.. well we could give it a shot! TTUL Ken -- MailChannels: Control Your Email http://www.mailchannels.com Ken Simpson, CEO +1-604-729-1741 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: How to tell if there's data waiting on a NON-blocking Apache connection?
Ken Simpson wrote: $c->client_socket gives you the socket object, now I suppose you want to poll() it for read. Unfortunately we haven't exposed APR::Poll yet. Take a look at the C API: http://lxr.webperf.org/source.cgi/srclib/apr/include/apr_poll.h http://docx.webperf.org/apr__poll_8h.html http://docx.webperf.org/group__apr__poll.html Is that what you are after? Yes, this is exactly what we need. Ideally, the APR interface should support the operations supported by IO::Select -- but it appears to. the APR::Socket object is an opaque one, so it can't interoperate with any other perl modules. Have you looked if there is some C api to get the native socket object? There could be one (as they have for file objects), I didn't check. How much work is it to write the mappings for APR::Poll? I've never done it before but.. well we could give it a shot! What C functions do you need to be exposed? it should be really quick if it can be exposed as is, without needing to write a special glue code... -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl2 and document_root
> Right. The examples you've found are from mod_perl 1, Apache2 has this > in its docs: > > /** > * Retrieve the document root for this server > * @param r The current request > * @warning Don't use this! If your request went through a Userdir, or > * something like that, it'll screw you. But it's back-compatible... > * @return The document root > * @deffunc const char *ap_document_root(request_rec *r) > */ > AP_DECLARE(const char *) ap_document_root(request_rec *r); > > we haven't had a chance yet to work on figuring out how to solve it for > mp2. Let me do some research and I'll be back to you shortly. in mp1 $r->document_root is misleading in the sense that it is _not_ locally scoped to $r - if you set it the change remains for all subsequent requests, since you are really altering the core configuration data. any example you find for mp1 _should_ include a mechanism for resetting $r->document_root to it's original value or it's misleading at best. something like this http://www.modperlcookbook.org/code/ch04/Cookbook/Userdir.pm is more proper than what you have. being able to alter DocumentRoot is valuable as long as you understand the ramifications, so I see no reason why we shouldn't continue to make it a writable feature in mp2. however, I very much dislike having it hang off of $r and would prefer it to hang off of $s so that people understand that its lifetime extends beyond the current request. --Geoff -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl2 and document_root
On Tue, Aug 17, 2004 at 04:45:20PM -0700, Stas Bekman wrote: > Right. The examples you've found are from mod_perl 1, Apache2 has this in > its docs: > > /** > * Retrieve the document root for this server > * @param r The current request > * @warning Don't use this! If your request went through a Userdir, or > * something like that, it'll screw you. But it's back-compatible... > * @return The document root > * @deffunc const char *ap_document_root(request_rec *r) > */ > AP_DECLARE(const char *) ap_document_root(request_rec *r); > > we haven't had a chance yet to work on figuring out how to solve it for > mp2. Let me do some research and I'll be back to you shortly. In Apache2, mod_userdir sets a note named "mod_userdir_user" in the r->notes table, so there is a way to detect if you are in a Userdir request (if using mod_userdir). However, that note only tells you the target user, not the path. The path is typically $HOME/public_html of the user, though that is configurable with the UserDir directive, so YMMV. Cheers, Glenn -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl2 and document_root
Glenn Strauss wrote: On Tue, Aug 17, 2004 at 04:45:20PM -0700, Stas Bekman wrote: Right. The examples you've found are from mod_perl 1, Apache2 has this in its docs: /** * Retrieve the document root for this server * @param r The current request * @warning Don't use this! If your request went through a Userdir, or * something like that, it'll screw you. But it's back-compatible... * @return The document root * @deffunc const char *ap_document_root(request_rec *r) */ AP_DECLARE(const char *) ap_document_root(request_rec *r); we haven't had a chance yet to work on figuring out how to solve it for mp2. Let me do some research and I'll be back to you shortly. In Apache2, mod_userdir sets a note named "mod_userdir_user" in the r->notes table, so there is a way to detect if you are in a Userdir request (if using mod_userdir). However, that note only tells you the target user, not the path. Ah, cool, thanks, I was just about to look at userdir The path is typically $HOME/public_html of the user, though that is configurable with the UserDir directive, so YMMV. So how do other applications that desire to rely on document_root get this special userdir doc-root? -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl2 and document_root
Geoffrey Young wrote: Right. The examples you've found are from mod_perl 1, Apache2 has this in its docs: /** * Retrieve the document root for this server * @param r The current request * @warning Don't use this! If your request went through a Userdir, or * something like that, it'll screw you. But it's back-compatible... * @return The document root * @deffunc const char *ap_document_root(request_rec *r) */ AP_DECLARE(const char *) ap_document_root(request_rec *r); we haven't had a chance yet to work on figuring out how to solve it for mp2. Let me do some research and I'll be back to you shortly. in mp1 $r->document_root is misleading in the sense that it is _not_ locally scoped to $r - if you set it the change remains for all subsequent requests, since you are really altering the core configuration data. any example you find for mp1 _should_ include a mechanism for resetting $r->document_root to it's original value or it's misleading at best. something like this http://www.modperlcookbook.org/code/ch04/Cookbook/Userdir.pm is more proper than what you have. being able to alter DocumentRoot is valuable as long as you understand the ramifications, so I see no reason why we shouldn't continue to make it a writable feature in mp2. however, I very much dislike having it hang off of $r and would prefer it to hang off of $s so that people understand that its lifetime extends beyond the current request. +1 the bigger problem (which i've explained on the dev list) in the parallel thread, is that under threaded mpms, that changing the document_root in one thread will affect all other threads, which is most certainly break things. So unless I'm missing something, that won't work for worker mpm. At the moment we have about 10 methods, which access server global structures and if you use those to set those structures, you limit your users to non-threaded mpms. -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl2 and document_root
On Tue, Aug 17, 2004 at 10:09:12PM -0700, Stas Bekman wrote: > >In Apache2, mod_userdir sets a note named "mod_userdir_user" in > >the r->notes table, so there is a way to detect if you are in a > >Userdir request (if using mod_userdir). However, that note only > >tells you the target user, not the path. > > Ah, cool, thanks, I was just about to look at userdir > > >The path is typically $HOME/public_html of the user, though > >that is configurable with the UserDir directive, so YMMV. > > So how do other applications that desire to rely on document_root get this > special userdir doc-root? There is no direct way in the Apache C API. One might pull the mod_userdir server config (peeking through the veil and requiring too much knowledge of mod_userdir internals). Then you'd still have to perform getpwnam() again to get the user homedir and then add the mod_userdir suffix. Messy. Of course, mod_userdir is not the only module out there which might perform filesystem mapping. mod_rewrite, Alias directives, and other custom userdir modules (e.g. that look users up in a db) might be in the mix. What is/are the problem(s) we're trying to solve here? We can use "mod_userdir_user" to detect that it is a userdir request and that document_root does not apply, even if we can't get the userdir root path. We can't easily do the same for other mappings. With regards to mod_userdir, I had a thought about patching it to also provide "mod_userdir_group" and "mod_userdir_path" notes. Does that sound like a useful thing? Or, instead of in r->notes, this sort of userdir information seems useful for a new sub-struct in the request_rec. Wish me luck suggesting that on [EMAIL PROTECTED] :) Cheers, Glenn -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
Re: mod_perl2 and document_root
Glenn Strauss wrote: [...] What is/are the problem(s) we're trying to solve here? We can use "mod_userdir_user" to detect that it is a userdir request and that document_root does not apply, even if we can't get the userdir root path. We can't easily do the same for other mappings. Well, actually, the question has nothing to do with userdir. I just thought (w/o looking at it) that it had some magical way to change ap_document_root that we didn't know about. But as you said, it doesn't. The problem we are trying to solve is how to allow users to change the document_root value in the server config structure, w/o affecting other threads if run in the threaded enviroment. We already agreed that it should be OK to change document_root in the non-threaded enviroment, where users will be responsible at restoring the value at the end of the request, should they wish to modify it. it worked perfectly fine in mod_perl 1, but it wasn't threaded. With regards to mod_userdir, I had a thought about patching it to also provide "mod_userdir_group" and "mod_userdir_path" notes. Does that sound like a useful thing? Or, instead of in r->notes, this sort of userdir information seems useful for a new sub-struct in the request_rec. Wish me luck suggesting that on [EMAIL PROTECTED] :) You will need more than just good luck. You should try to wait for the next big meteorite rain and who knows that may just work. -- __ 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 -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
