$r-path_info question
Hi all, I am using $r-path_info in an Apache handler. The handler is set via a Location directive: Location /cgi-bin/detail.pl # Overcoming Legacy code :-) SetHandler perl-script PerlHandler eLogix::Images::Detail /Location And is called like "/cgi-bin/detail.pl/A1234567.jpg". My question is this: Since there is no physical filename which corresponds to the URL, what does path_info contain? In the eagle book on page 135, when path_info is first discussed, the example uses $r-lookup_uri($path_info) to get the filename, which in this example is a purely virtual tree. I currently am using my $filename = (split /\//, $r-path_info)[1]; but it seems like such a hack. What is the "suggested" way to get the "A1234567.jpg" part of the above URL? -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: $r-path_info question
Drew Taylor said... Hi all, Hi. I currently am using my $filename = (split /\//, $r-path_info)[1]; but it seems like such a hack. What is the "suggested" way to get the "A1234567.jpg" part of the above URL? Since Apache sets path_info by scanning the physical filesystem, and since you are overcoming legacy calls to a script inside cgi-bin, your solution is probably just fine. I had a similar issue in the past: http://forum.swarthmore.edu/epigone/modperl/smumbabax As Doug mentions in that thread, $r-location might be of some assistance. Hope this helps. -- David S. Kenzik [EMAIL PROTECTED] - http://kenzik.com
Re: $r-path_info question
David Kenzik wrote: Drew Taylor said... I currently am using my $filename = (split /\//, $r-path_info)[1]; but it seems like such a hack. What is the "suggested" way to get the "A1234567.jpg" part of the above URL? Since Apache sets path_info by scanning the physical filesystem, and since you are overcoming legacy calls to a script inside cgi-bin, your solution is probably just fine. I had a similar issue in the past: http://forum.swarthmore.edu/epigone/modperl/smumbabax As Doug mentions in that thread, $r-location might be of some assistance. That was an interesting thread. However, I think Eric found the easiest solution for me. This handler is very simple and if the requested file does not pass -e, it just returns NOT_FOUND. So I guess I'll stick with my original thinking for now. Thanks. -- Drew Taylor Vialogix Communications, Inc. 501 N. College Street Charlotte, NC 28202 704 370 0550 http://www.vialogix.com/
Re: $r-path_info question
Hi all, I am using $r-path_info in an Apache handler. The handler is set via a Location directive: Location /cgi-bin/detail.pl # Overcoming Legacy code :-) SetHandler perl-script PerlHandler eLogix::Images::Detail /Location And is called like "/cgi-bin/detail.pl/A1234567.jpg". My question is this: Since there is no physical filename which corresponds to the URL, what does path_info contain? In the eagle book on page 135, when path_info is first discussed, the example uses $r-lookup_uri($path_info) to get the filename, which in this example is a purely virtual tree. $r-path_info contains what's left of the URI after it's been mapped to a (virtual) file, in your case /A1234567.jpg I currently am using my $filename = (split /\//, $r-path_info)[1]; or you could have used (my $filename = $r-path_info) =~ s!^/!!; but it seems like such a hack. What is the "suggested" way to get the "A1234567.jpg" part of the above URL? Since you have no trailing slash in your Location directive, you get a leading / in path_info. What would be the filename if the request URI was /cgi-bin/detail.pl/foo/bar.jpg ? In that case path_info will be '/foo/bar.jpg'. Maybe what you really want is my $filename = (split /\//, $r-path_info)[-1]; whatever... it's completely up to the application to define the semantics of path_info. -- Drew Taylor -- Eric
ANNOUNCE: HTML::StickyForms 0.02
OK, this time I've remembered to say what the module actually does: This a lightweight form generation module, which can be used with either CGI.pm, or (inside mod_perl) Apache::Request. The module provides similar facilities to CGI.pm's HTML tag generation routines, but is restricted to form field generation tags, with sticky values. Also, the interface is not so flexible as CGI.pm's, in order to keep the code size down. Changes since version 0.01: Added select() Combined checkbox_group() and radio_group() Added documentation --- Begin Forwarded Message --- The uploaded file HTML-StickyForms-0.02.tar.gz has entered CPAN as file: $CPAN/authors/id/P/PM/PMH/HTML-StickyForms-0.02.tar.gz size: 4716 bytes md5: c2c216faba385af3186a3e5d83923700 No action is required on your part Request entered by: PMH (Peter Haworth) Request entered on: Tue, 27 Jun 2000 13:42:55 GMT Request completed: Tue, 27 Jun 2000 13:43:58 GMT Virtually Yours, Id: paused,v 1.68 1999/10/22 14:39:12 k Exp k --- End Forwarded Message --- -- Peter Haworth [EMAIL PROTECTED] Duck! Where?
Apache::Include requires ExecCGI on doc root?
I was experimenting with Apache::Include and found something odd. First I tried a document in htdocs that used a virtual include like so: !--#include virtual="/perl/hello-mod_perl.pl" -- This works fine, and hello-mod_perl.pl runs via Apache::Registry. But when I changed the include to use Apache::Include like so: !--#perl sub="Apache::Include" arg="/perl/hello-mod_perl.pl" -- it didn't work, and I got an error in error_logs: [Tue Jun 27 11:22:59 2000] [error] access to /usr/local/apache/perl/hello-mod_perl.pl failed for 192.168.3.9, reason: Options ExecCGI is off in this directory I verified that ExecCGI is enabled for /usr/local/apache/perl (besides, the Apache::Registry version wouldn't have worked without it). Turns out that Apache::Include worked fine when I enabled ExecCGI for htdocs. Is there a reason why Apache::Include requires this when mod_include doesn't? Regards, ..Theo -- Theo Petersenmailto:[EMAIL PROTECTED] "Well, let's get back to work; the world isn't going to end itself." --MST3K, "The Space Children"
Apache::Config module
Hi all-
I've written a module that can parse the Apache httpd.conf config file
(and in fact any Apache-like config file). It will take a set of
directive like:
ServerName www.mydomain.com
UseCanonicalName Off
And parse it case-insensitively, returning a ref to a hash:
my $ac = new Apache::Config;
my $conf = $ac-readconf($configfile);
print $conf-{servername}; # = "www.mydomain.com";
print $conf-{usecanonicalname}; # = 0 (not undef so can test
#for defined() still)
I am also finishing up the ability to parse within contexts, such as
Directory and Location. I am still unsure of the interface, I have
two ideas:
1. multi-level hash, i.e.
$conf-{"directory /"}-{sethandler}
2. individual functions, i.e.
$conf-directory("/")-{sethandler}
If anyone has any input, I'm all ears. Right now I'm leaning towards the
second one, if I can get it working. The first one is really flexible
and easy, the problem is that it's difficult to search. The second one
helps with this issue, but the downside is that new functions have to be
added if new Apache contexts are defined. I'm trying to play some tricks
with the AutoLoader ala Shell to get new functions defined on the fly.
If anyone has good ideas for a better interface, I'd also like to hear
them.
In any case, I have several questions:
1. Does a module like this exist anywhere? I saw Doug's
Apache::httpd_conf, but this only takes care of writing
a very minimal config file. I looked thru all the
Apache:: modules but didn't see one.
2. Is the name Apache::Config a good name for this module?
It seems like the obvious choice to me, and doesn't
look like it's taken. I've also played around with
Apache::ConfigFile and Apache::ReadConf, either of
which I'm open to as well (or other suggestions?).
I'm aware of the Apache and Apache::Constants modules, which do provide
Apache API methods for getting to this data that work great for
mod_perl. My goal with this module was to make it general enough to be
used to parse any Apache-style config file. That way, if you wanted (a)
write a CGI script outside of mod_perl that used httpd.conf data, or (b)
wrote a custom (maybe non-web) app that used an Apache-like config file,
you could get at the data quickly. In this way it would be like
Apache::Session, where it can work either in a CGI or mod_perl context.
Thanks for your help and input.
-Nate
Re: Mason--Passing references to components
Thanks for the reply. I'm glad to see that Mason handles them in the
expected way. As it turns out, I was handling them correctly, I was simply
chasing a red herring because (I'm new to Mason) I failed to notice that
the line references in the error output were keyed to the file in data/obj
and not my file. Once I sorted that out I immediately saw the real problem.
Bill
At 9:13 AM +0200 6/27/00, Francesc Guasch wrote:
Bill McCabe wrote:
Hi All
I'm converting a mod_perl module-based site to HTML::Mason and have a
question about passing arguments to a component.
my $penuser = $r-connection-user;
my $authzrc = $m-comp( 'authzREPSYS', data_aref=\@data_refs,
hconnref=\%hconn, penuser=$penuser );
this works for me, later you declare data:
%args
$data_aref
$hconnref
$penuser
/%args
And remember to use it as refs:
% foreach (@$data_aref) {
% $_ br
% }
Maybe you'r error is there, make sure you check perldoc perlref
--
- frankie -
possible distributed session server
Saw this on Freshmeat today. It looks like it could be useful for handling session data within a cluster, as a low-end alternative to expensive replicated RDBMS stuff. http://www.fault-tolerant.org/recall/ - Perrin
mod_perl install
mod_perl'ers, I got mod_perl to compile and rebuild httpd, but the new httpd did not have the prefix correct (it used the default location). I have 2 questions; 1) What do I need to do to get the correct prefix to the httpd build when compiling from the mod_perl scripts? 2) What is the procedure to set up the mod_perl installation so that I can build it using the httpd installation scripts? Thanks Mike respond using [EMAIL PROTECTED]
RE: mod_perl install
you may want to see http://perl.apache.org/guide/install.html specifically http://perl.apache.org/guide/install.html#APACHE_PREFIX HTH --Geoff -Original Message- From: Michael L. Stokes [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 27, 2000 11:46 AM To: [EMAIL PROTECTED] Subject: mod_perl install mod_perl'ers, I got mod_perl to compile and rebuild httpd, but the new httpd did not have the prefix correct (it used the default location). I have 2 questions; 1) What do I need to do to get the correct prefix to the httpd build when compiling from the mod_perl scripts? 2) What is the procedure to set up the mod_perl installation so that I can build it using the httpd installation scripts? Thanks Mike respond using [EMAIL PROTECTED]
FreeBSD: semwai state Help..
Hi All, I'm having a very strange problem and am hoping someone on here can help. I'm running a typical Apache(1.3.6), mod_perl(1.21), Mason(0.81), mySQL set-up on 4 big RAM machines (database is on other machines). I start up the servers and after a few minutes the state of the processes ends up as "semwai" and the apache processes just stop taking requests. Here's a quick glance at some output from top: 50201 www -4 0 15544K 10352K semwai 0:00 0.00% 0.00% apache 50249 www -4 0 15432K 10280K semwai 0:00 0.00% 0.00% apache 50227 www -4 0 15428K 9808K semwai 0:00 0.00% 0.00% apache Tried many different combinations of MaxClients, MaxRequestsPerChild, along with KeepAlive On/Off, nothing seems to help. Currently I'm at 48 servers on each of 4 machines, mySQL is set-up to take over 800 connections (so the 100 limit has already been modified.) Not swapping, not heavily loaded.. Roughly only 30 connections to any specific machine at one time. Has anyone seen this or better yet what's the cause or some suggested things to look at or fix? Thanks -- Jeff Gleixner Steven Wright Saying of the moment: I like to fill my tub up with water, then turn the shower on and act like I'm in a submarine that's been hit.
Apache::Upload ?
howdy. one of the requirement of the system that I'm developing, is the ability for a user to upload a document from their local system and have it stored in a database (mysql in this case).. I have traditionally used the file upload features of CGI.pm for this type of action, but as I am in a dedicated mod_perl environment, I wanted to see if there was a more 'mod_perl way' to do this. I though I found what I was looking for on http://perl.apache.org/src/apache-modlist.html under the "* Misc" heading.. "Upload amcOFile upload class APML" and according to the notes on that page.. "Modules listed with the APML as is contact are part of the mod_perl distribution package." OK.. so it's standard with the mod_perl dist. But is it really? I can not find *any* reference to it in my perl install, which has mod_perl 1.24 installed. perldoc turns up nothing.. [backplate@freak backplate]$ perldoc Apache::Upload No documentation found for "Apache::Upload". and I don't see an 'Upload.pm' anywhere.. can anyone point me in the right direction? I'm running Apache/1.3.12 (Unix) mod_perl/1.24 compiled with perl5.6.0 .. basicly, I'm looking for documentation on usage.. Thanks in advance! -Casey
Re: Apache::Config module
Nathan Wiger [EMAIL PROTECTED] wrote:
Hi all-
I've written a module that can parse the Apache httpd.conf config file
(and in fact any Apache-like config file). It will take a set of
directive like:
[snip]
I am also finishing up the ability to parse within contexts, such as
Directory and Location. I am still unsure of the interface, I have
two ideas:
1. multi-level hash, i.e.
$conf-{"directory /"}-{sethandler}
2. individual functions, i.e.
$conf-directory("/")-{sethandler}
Perhaps
3. multi-level hash, i.e.
$conf-{directory}-{'/'}-{sethandler}
This is, afaik, more in-line with what the Perl.../Perl sections do. I
would suggest making it so the output of this module could easily be fed into
the mod_perl configuration engine in the Perl sections. This gives us the
ease of the second example with the programming simplicity of the first (i.e.,
no new functions).
We can also pull out the information we might want: I can get a list of all
the directories I'm configuring with the first or third method, but the first
is messy. The second method doesn't give us an obvious solution to this.
Even though I would not suggest configuring Apache by reading in a
configuration file and feeding it to the mod_perl engine, it does have a
certain aesthetic appeal to me... besides, I only have to learn one way of
thinking about it :)
--
James Smith [EMAIL PROTECTED], 979-862-3725
Texas AM CIS Operating Systems Group, Unix
Re: Apache::Upload ?
Thanks for the pointer.. the only hitch I am running into is: embarrassed expression when I do a 'perldoc Apache::Request' on my system, I get our friendly No documentation found for "Apache::Request". I *know* I am using the perldoc for the version of perl that has mod_perl installed.. if I do 'perldoc Apache' .. I get the docs.. this is consitant in two mod_perl installs on two seperate systems.. given, I installed them both.. so I'm thinking that I errored in the install and some docs didn't get installed.. anybody ever have similar issues with the docs? I've been developing mod_perl dependent code in this particular env for several weeks and everything has been working thus far.. so I belive the install is complete.. am I just dropping the ball and doing something stupid? /embarrassed expression Thanks! Your reciently humbled mod_perl hacker.. -Casey On Tue, 27 Jun 2000, Tobias Hoellrich wrote: Take a look at Apache::Request which is what you want. The documentation for Apache::Upload is contained in the 'perldoc Apache::Request' . Hope this helps Tobias At 02:17 PM 6/27/00 -0600, Casey Bristow wrote: howdy. one of the requirement of the system that I'm developing, is the ability for a user to upload a document from their local system and have it stored in a database (mysql in this case).. I have traditionally used the file upload features of CGI.pm for this type of action, but as I am in a dedicated mod_perl environment, I wanted to see if there was a more 'mod_perl way' to do this. I though I found what I was looking for on http://perl.apache.org/src/apache-modlist.html under the "* Misc" heading.. "Upload amcOFile upload class APML" and according to the notes on that page.. "Modules listed with the APML as is contact are part of the mod_perl distribution package." OK.. so it's standard with the mod_perl dist. But is it really? I can not find *any* reference to it in my perl install, which has mod_perl 1.24 installed. perldoc turns up nothing.. [backplate@freak backplate]$ perldoc Apache::Upload No documentation found for "Apache::Upload". and I don't see an 'Upload.pm' anywhere.. can anyone point me in the right direction? I'm running Apache/1.3.12 (Unix) mod_perl/1.24 compiled with perl5.6.0 .. basicly, I'm looking for documentation on usage.. Thanks in advance! -Casey -- -Casey
IPC::ShareLite 0.07a test problems
Hey, I realize this problem isn't directly mod-perl related, but I'm trying to build the most up-to-date version of perl/apache/etc to continue debugging the problem I'm having with set_handlers() (see other recent thread). I'm using IPC::Cache (which of course relies on IPC::ShareLite) within an AuthzCache module. I'm finding test errors in IPC::ShareLite-0.07a under solaris 2.5.1/perl-5.6.0. Below is the output of a gdb on the test. Has anyone successfully compiled and tested ShareLite in a similar environment? Regards, Christian cougar% gdb perl-5.60 GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.5.1"... (gdb) set args test.pl (gdb) r Starting program: /opt/gnu/bin/perl-5.60 test.pl 1..8 ok 1 ok 2 ok 3 not ok 4 ok 5 ok 6 not ok 7 Bad realloc() ignored at /opt/gnu/depot/perl-5.6.0/lib/site_perl/sun4-solaris/IPC/ShareLite.pm line 106. Program received signal SIGSEGV, Segmentation fault. 0x79568 in Perl_sv_usepvn () (gdb) share Symbols already loaded for /usr/lib/libsocket.so.1 Symbols already loaded for /usr/lib/libnsl.so.1 Symbols already loaded for /usr/lib/libdl.so.1 Symbols already loaded for /usr/lib/libm.so.1 Symbols already loaded for /usr/lib/libc.so.1 Symbols already loaded for /usr/lib/libsec.so.1 Symbols already loaded for /usr/lib/libintl.so.1 Symbols already loaded for /usr/lib/libmp.so.1 Symbols already loaded for /usr/lib/libw.so.1 Symbols already loaded for /opt/gnu/depot/perl-5.6.0/lib/site_perl/sun4-solaris/auto/IPC/ShareLite/Shar eLite.so (gdb) bt #0 0x79568 in Perl_sv_usepvn () #1 0xef58327c in XS_IPC__ShareLite_read_share (cv=0x161f80) at ShareLite.xs:314 #2 0x73114 in Perl_pp_entersub () #3 0x6c0cc in Perl_runops_standard () #4 0x23eb0 in S_run_body () #5 0x23b18 in perl_run () #6 0x2115c in main () - Christian Gilmore Infrastructure Tools Team Lead Web Multimedia Development Tivoli Systems, Inc.
Re: Apache::Config module
James-
You might want to reconsider the usecanonicalname setting. The hash element
should exist if and only if it appears in the configuration file. It should
be defined if and only if it has an argument in the configuration file.
Thus, the following results:
UseCanonicalName
results in $conf-{usecanonicalname} == undef
UseCanonicalName Off
results in $conf-{usecanonicalname} == 0
Then use existance in the hash array to test existance in the configuration
file. You may have already been thinking along this line. If so, then I'm
only clarifying a point...
You're exactly right - that's why I make a distinction between 0, 1, and
undef, so:
UseCanonicalName On# = 1
UseCanonicalName Off # = 0
#UseCanonicalName On# = undef (commented out)
That way, the logic in your script/module/whatever can set a default
value:
if ( ! defined($conf-{usecanonicalname}) ) {
# not specified, set default(s)
} elsif ( ! $conf-{usecanonicalname} ) {
# explicitly turned off
} else {
# explicitly turned on
}
This lets you default to any value you want (on or off). Does this help
clarify?
Regarding this:
Perhaps
3. multi-level hash, i.e.
$conf-{directory}-{'/'}-{sethandler}
This is, afaik, more in-line with what the Perl.../Perl sections do. I
would suggest making it so the output of this module could easily be fed into
the mod_perl configuration engine in the Perl sections. This gives us the
ease of the second example with the programming simplicity of the first (i.e.,
no new functions).
I actually like this alot. My question would be how to parse something
that didn't have one element, or that had multiple ones, for example I
can envision:
Perl /Perl
SomeContext "/a" "/b" /SomeContext
The first one exists, while the second one is (as far as I'm aware) only
theoretical. However, should they be solved as:
$conf-{perl}-{somesetting}
$conf-{somecontext}-{'/a'}-{'/b'}-{somesetting}
Input??? I just want to plan this out from the start so that as things
are added later the syntax and/or structures don't get unwieldy. I don't
want to change the "API" to such a module once it's out there.
Thanks again for the feedback.
-Nate
Re: Apache::Upload ?
Take a look at Apache::Request which is what you want. The documentation for Apache::Upload is contained in the 'perldoc Apache::Request' . Hope this helps Tobias At 02:17 PM 6/27/00 -0600, Casey Bristow wrote: howdy. one of the requirement of the system that I'm developing, is the ability for a user to upload a document from their local system and have it stored in a database (mysql in this case).. I have traditionally used the file upload features of CGI.pm for this type of action, but as I am in a dedicated mod_perl environment, I wanted to see if there was a more 'mod_perl way' to do this. I though I found what I was looking for on http://perl.apache.org/src/apache-modlist.html under the "* Misc" heading.. "Upload amcOFile upload class APML" and according to the notes on that page.. "Modules listed with the APML as is contact are part of the mod_perl distribution package." OK.. so it's standard with the mod_perl dist. But is it really? I can not find *any* reference to it in my perl install, which has mod_perl 1.24 installed. perldoc turns up nothing.. [backplate@freak backplate]$ perldoc Apache::Upload No documentation found for "Apache::Upload". and I don't see an 'Upload.pm' anywhere.. can anyone point me in the right direction? I'm running Apache/1.3.12 (Unix) mod_perl/1.24 compiled with perl5.6.0 .. basicly, I'm looking for documentation on usage.. Thanks in advance! -Casey
Re: FreeBSD: semwai state Help..
From: Jeff Gleixner [EMAIL PROTECTED] Date: Tue, 27 Jun 2000 14:23:20 -0500 Subject: FreeBSD: semwai state Help.. To: [EMAIL PROTECTED] Hi All, I'm having a very strange problem and am hoping someone on here can help. I'm running a typical Apache(1.3.6), mod_perl(1.21), Mason(0.81), mySQL set-up on 4 big RAM machines (database is on other machines). I start up the servers and after a few minutes the state of the processes ends up as "semwai" and the apache processes just stop taking requests. Here's a quick glance at some output from top: 50201 www -4 0 15544K 10352K semwai 0:00 0.00% 0.00% apache 50249 www -4 0 15432K 10280K semwai 0:00 0.00% 0.00% apache 50227 www -4 0 15428K 9808K semwai 0:00 0.00% 0.00% apache I am not familiar with that state from top, but it looks like it is waiting for a semaphore. I would suggest reading up on shared memory segments and semaphores, in whatever kernel manuals you have for your OS. I know that on Solaris, I have to up the default values quite a bit to get things to work with Oracle properly. This makes sense too, as an OS should not be tuned for db access unless necessary, so the default config is fine for non-db access apps. :):) David McCabe Unix System Administrator Le Groupe Videotron [EMAIL PROTECTED] (514) 380 4433 When in doubt, parenthesize. At the very least it will let some poor schmuck bounce on the % key in vi. Programming Perl, Chapter 8, Programming with Style
