cvs commit: modperl-2.0/lib/ModPerl Code.pm
dougm 2002/06/29 12:43:51
Modified:lib/ModPerl Code.pm
Log:
provide mechanism to #ifdef constants
add APLOG_TOCLIENT to the list of #ifdef constants
Revision ChangesPath
1.84 +20 -2 modperl-2.0/lib/ModPerl/Code.pm
Index: Code.pm
===
RCS file: /home/cvs/modperl-2.0/lib/ModPerl/Code.pm,v
retrieving revision 1.83
retrieving revision 1.84
diff -u -r1.83 -r1.84
--- Code.pm 21 Jun 2002 00:05:49 - 1.83
+++ Code.pm 29 Jun 2002 19:43:51 - 1.84
-718,6 +718,18
REDIRECT = 'HTTP_MOVED_TEMPORARILY',
);
+my %ifdef = map { $_, 1 } qw(APLOG_TOCLIENT);
+
+sub constants_ifdef {
+my $name = shift;
+
+if ($ifdef{$name}) {
+return (#ifdef $name\n, #endif /* $name */\n);
+}
+
+(, );
+}
+
sub constants_lookup_code {
my($h_fh, $c_fh, $constants, $class) = _;
-761,10 +773,13
print $c_fh case '$key':\n;
for my $name ($names) {
+my ifdef = constants_ifdef($alias{$name});
print $c_fh EOF;
+$ifdef[0]
if (strEQ(name, $name)) {
return $alias{$name};
}
+$ifdef[1]
EOF
}
print $c_fh break;\n;
-806,8 +821,11
push tags, $group;
my $name = join '_', 'MP_constants', $class, $group;
print $c_fh \nstatic const char *$name [] = { \n,
- (map { s/^($constant_prefixes)_?//o;
- qq( $_,\n) } $constants),NULL,\n};\n;
+ (map {
+ my ifdef = constants_ifdef($_);
+ s/^($constant_prefixes)_?//o;
+ qq($ifdef[0] $_,\n$ifdef[1])
+ } $constants),NULL,\n};\n;
}
my %switch;
cvs commit: modperl-2.0 Makefile.PL
dougm 2002/06/29 12:44:04 Modified:.Makefile.PL Log: now that APLOG_TOCLIENT is #ifdef-ed, allow compilation with 2.0.35 Revision ChangesPath 1.87 +1 -1 modperl-2.0/Makefile.PL Index: Makefile.PL === RCS file: /home/cvs/modperl-2.0/Makefile.PL,v retrieving revision 1.86 retrieving revision 1.87 diff -u -r1.86 -r1.87 --- Makefile.PL 23 Jun 2002 21:46:09 - 1.86 +++ Makefile.PL 29 Jun 2002 19:44:04 - 1.87 -2,7 +2,7 use strict; use warnings FATAL = 'all'; -my $min_httpd_version = '2.0.36'; +my $min_httpd_version = '2.0.35'; my($old_modperl_version, $old_modperl_pm);
cvs commit: modperl-2.0/src/modules/perl mod_perl.c modperl_cgi.c modperl_filter.c modperl_types.h
dougm 2002/06/29 13:38:33
Modified:src/modules/perl mod_perl.c modperl_cgi.c modperl_filter.c
modperl_types.h
Log:
add support for redirects with PerlOptions +ParseHeaders
Revision ChangesPath
1.130 +7 -0 modperl-2.0/src/modules/perl/mod_perl.c
Index: mod_perl.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/mod_perl.c,v
retrieving revision 1.129
retrieving revision 1.130
diff -u -r1.129 -r1.130
--- mod_perl.c28 Jun 2002 19:15:51 - 1.129
+++ mod_perl.c29 Jun 2002 20:38:33 - 1.130
-709,6 +709,13
/* flush output buffer after interpreter is putback */
modperl_response_finish(r);
+switch (rcfg-status) {
+ case HTTP_MOVED_TEMPORARILY:
+/* set by modperl_cgi_header_parse */
+retval = HTTP_MOVED_TEMPORARILY;
+break;
+}
+
return retval;
}
1.2 +33 -0 modperl-2.0/src/modules/perl/modperl_cgi.c
Index: modperl_cgi.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_cgi.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- modperl_cgi.c 8 May 2001 18:04:36 - 1.1
+++ modperl_cgi.c 29 Jun 2002 20:38:33 - 1.2
-5,6 +5,7
{
int status;
int termarg;
+const char *location;
if (!buffer) {
return DECLINED;
-12,6 +13,38
status = ap_scan_script_header_err_strs(r, NULL, bodytext,
termarg, buffer, NULL);
+
+/* code below from mod_cgi.c */
+location = apr_table_get(r-headers_out, Location);
+
+if (location (location[0] == '/') (r-status == 200)) {
+r-method = apr_pstrdup(r-pool, GET);
+r-method_number = M_GET;
+
+/* We already read the message body (if any), so don't allow
+ * the redirected request to think it has one. We can ignore
+ * Transfer-Encoding, since we used REQUEST_CHUNKED_ERROR.
+ */
+apr_table_unset(r-headers_in, Content-Length);
+
+ap_internal_redirect_handler(location, r);
+
+return OK;
+}
+else if (location (r-status == 200)) {
+MP_dRCFG;
+
+/* Note that if a script wants to produce its own Redirect
+ * body, it now has to explicitly *say* Status: 302
+ */
+
+/* XXX: this is a hack.
+ * filter return value doesn't seem to impact anything.
+ */
+rcfg-status = HTTP_MOVED_TEMPORARILY;
+
+return HTTP_MOVED_TEMPORARILY;
+}
return status;
}
1.36 +4 -1 modperl-2.0/src/modules/perl/modperl_filter.c
Index: modperl_filter.c
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_filter.c,v
retrieving revision 1.35
retrieving revision 1.36
diff -u -r1.35 -r1.36
--- modperl_filter.c 30 May 2002 02:33:48 - 1.35
+++ modperl_filter.c 29 Jun 2002 20:38:33 - 1.36
-14,7 +14,10
const char *bodytext = NULL;
int status = modperl_cgi_header_parse(r, (char *)buf, bodytext);
-if (status != OK) {
+if (status == HTTP_MOVED_TEMPORARILY) {
+return APR_SUCCESS; /* XXX: HTTP_MOVED_TEMPORARILY ? */
+}
+else if (status != OK) {
ap_log_error(APLOG_MARK, APLOG_WARNING|APLOG_NOERRNO,
0, r-server, %s did not send an HTTP header,
r-uri);
1.60 +1 -0 modperl-2.0/src/modules/perl/modperl_types.h
Index: modperl_types.h
===
RCS file: /home/cvs/modperl-2.0/src/modules/perl/modperl_types.h,v
retrieving revision 1.59
retrieving revision 1.60
diff -u -r1.59 -r1.60
--- modperl_types.h 21 Jun 2002 03:02:54 - 1.59
+++ modperl_types.h 29 Jun 2002 20:38:33 - 1.60
-205,6 +205,7
HV *pnotes;
SV *global_request_obj;
U8 flags;
+int status;
modperl_wbucket_t *wbucket;
MpAV *handlers_per_dir[MP_HANDLER_NUM_PER_DIR];
MpAV *handlers_per_srv[MP_HANDLER_NUM_PER_SRV];
Need Porting Sanity Check
Title: Message I have a 'medium' traffic e-commerce site (about 30GB xfer a month). It is mostly written in Perl (about 40 scripts or 4,000 lines of code). We have had no problems with performance to date but in preparation for future growth (in addition to other changes to the site's scripts) I thought it would be a good idea to switch from CGI to Mod_Perl. I read all of Stas Bekman's Porting Guidelines and looked at my scripts.While Ihave a long programming history, I must admit I started cranking out the code (ina nice modular fashion) as soon as I grasped the basic of the language, ignoring things like the -w operator, use strict;, andonly used variable localization (my) in someof my subroutines. I have determined that as a result, I would have quite a bit of work to do to move to modPerl (using Apache::Registry) including: - avoid inner subrouting nesting problem by having all Perl scripts called by the webserver only executive code in included files (using require from a main script) - make all variables localized using 'my' and special variables using local (although my coding is sloppy from a localization standpoint, it is written so it doesn't even need global variables - all variables are passed through the subroutines properly even though I forgot to specifically localize them) - Make sure required files are reloaded after modification bysetting PerlInitHandler to Reload, Setting PerlSetVar ReloadAll Off, and then when I am developing including Apacher::Reload in the scripts I am working on, then taking it out when they go into production (this was the method that made the most sense to me.) - I actually didn't really understand the problem with testing from the shell and using CGI::Switch or CGI.pm - Use '^T = time' in the scripts that I test filetime to determine its age - Use 'open my $fh, $filename or die $!; wherever I open files to insure they get closed properly That's going to be A LOT of work and I have lots of other modifications to do. So then I get to his section titled 'Apache::PerlRun--a closer look' and come to find out that Apache:PerlRun is basically a nice compromise offering some (not all) of the performance benefits of mod_Perl while not forcing you to have to drastically clean up your code. So here is my strategy that I would like a sanity check from anyone on. Go through and quickly clean up my existing code by adding use strict andlocalizing all my variables (with 'my' and 'local' for special variables) and then run is under mod_Perl using the Apache::PerlRun. Write all my new code so that it will run under Apache::Registry and then when I have spare time (ya right) go work on porting the older code. On thing that is interesting is that even though I added the -w operator to the end of #!/usr/bin/perl in my scripts and added use stricts; I am not seeing the hundreds of error messages I should see in either error_log or suexec_log. Any ideas? Thanks.
Need Porting Sanity Check
Title: Message Excuse my typos, I just wanted to clarify I added 'use strict;' not 'use stricts;' to my code along with the -w operator(#!/usr/bin/perl -w) and I'm not seeing all the errors in my logs.
FW: mod_perl_make error
Title: FW: mod_perl_make error Hello Any help appreciated with this attempt to make mod_perl 1.27 on hp-ux 11.11, 64 bit OS, apache 1.3.26 and perl 5.6.1. Rdgs Richard To: [EMAIL PROTECTED] Subject: mod_perl_make error Script started on Fri Jun 28 15:35:13 2002 # pwd /.cpan/build/mod_perl-1.27 # perl -V Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=hpux, osvers=11.11, archname=PA-RISC2.0-thread uname='hp-ux bianca b.11.11 u 9000800 1493622342 unlimited-user license ' config_args='-Ubincompat5005 -Duse64bitall' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=define useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define use64bitall=define uselongdouble=undef Compiler: cc='/opt/ansic/bin/cc', ccflags =' -D_HPUX_SOURCE +DD64 -Ae -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 +z -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 ', optimize='-O', cppflags='-D_HPUX_SOURCE +DD64 -Ae -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 +z' ccversion='B.11.11.04', gccversion='', gccosandvers='' intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=87654321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='/usr/bin/ld', ldflags ='+DD64 -Wl,+vnocompatwarnings -L/usr/local/lib -L/lib/pa20_64' libpth=/usr/local/lib /lib/pa20_64 /lib /usr/lib /usr/ccs/lib libs=-lcl -lpthread -lnsl -lnm -ldld -lm -lc -lsec perllibs=-lcl -lpthread -lnsl -lnm -ldld -lm -lc -lsec libc=/lib/pa20_64/libc.sl, so=sl, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_hpux.xs, dlext=sl, d_dlsymun=undef, ccdlflags='-Wl,-E -Wl,-B,deferred ' cccdlflags='+z', lddlflags='-b +vnocompatwarnings -L/usr/local/lib -L/lib/pa20_64' Characteristics of this binary (from libperl): Compile-time options: USE_THREADS USE_64_BIT_INT USE_64_BIT_ALL USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Built under hpux Compiled at Jun 28 2002 11:20:20 @INC: /opt/perl5/lib/5.6.1/PA-RISC2.0-thread /opt/perl5/lib/5.6.1 /opt/perl5/lib/site_perl/5.6.1/PA-RISC2.0-thread /opt/perl5/lib/site_perl/5.6.1 /opt/perl5/lib/site_perl . # make (cd /home/rgarring/perl/apache_1.3.26/src PERL5LIB=/.cpan/build/mod_perl-1.27/lib: make CC=/opt/ansic/bin/cc;) === regex === regex === os/unix rm -f libos.a ar cr libos.a os.o os-inline.o /bin/true libos.a === os/unix === ap rm -f libap.a ar cr libap.a ap_cpystrn.o ap_execve.o ap_fnmatch.o ap_getpass.o ap_md5c.o ap_signal.o ap_slack.o ap_snprintf.o ap_sha1.o ap_checkpass.o ap_base64.o ap_ebcdic.o ap_strtol.o /bin/true libap.a === ap === main ./gen_test_char test_char.h /opt/ansic/bin/cc -c -I.. -I/opt/perl5/lib/5.6.1/PA-RISC2.0-thread/CORE -I../os/unix -I../include -DHPUX11 -Aa -Ae -D_HPUX_SOURCE -DMOD_PERL -DUSE_PERL_SSI -D_HPUX_SOURCE +DD64 -Ae +z -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DUSE_HSREGEX -DUSE_EXPAT -I../lib/expat-lite -DNO_DL_NEEDED -D_HPUX_SOURCE +DD64 -Ae -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 +z -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DMOD_PERL util.c rm -f libmain.a ar cr libmain.a alloc.o buff.o http_config.o http_core.o http_log.o http_main.o http_protocol.o http_request.o http_vhost.o util.o util_date.o util_script.o util_uri.o util_md5.o rfc1413.o /bin/true libmain.a === main === lib === lib/expat-lite === lib/expat-lite === lib === modules === modules/standard rm -f libstandard.a ar cr libstandard.a mod_env.o mod_log_config.o mod_mime.o mod_negotiation.o mod_status.o mod_include.o mod_autoindex.o mod_dir.o mod_cgi.o mod_asis.o mod_imap.o mod_actions.o mod_userdir.o mod_alias.o mod_access.o mod_auth.o mod_setenvif.o /bin/true libstandard.a === modules/standard === modules/perl === modules/perl === modules /opt/ansic/bin/cc -c -I. -I/opt/perl5/lib/5.6.1/PA-RISC2.0-thread/CORE -I./os/unix -I./include -DHPUX11 -Aa -Ae -D_HPUX_SOURCE -DMOD_PERL -DUSE_PERL_SSI -D_HPUX_SOURCE +DD64 -Ae +z -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DUSE_HSREGEX -DUSE_EXPAT -I./lib/expat-lite -DNO_DL_NEEDED -D_HPUX_SOURCE +DD64 -Ae -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 +z -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DMOD_PERL modules.c /opt/ansic/bin/cc -c -I. -I/opt/perl5/lib/5.6.1/PA-RISC2.0-thread/CORE -I./os/unix -I./include -DHPUX11 -Aa -Ae -D_HPUX_SOURCE -DMOD_PERL -DUSE_PERL_SSI -D_HPUX_SOURCE +DD64 -Ae +z -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DUSE_HSREGEX -DUSE_EXPAT -I./lib/expat-lite -DNO_DL_NEEDED -D_HPUX_SOURCE +DD64 -Ae -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 +z -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DMOD_PERL buildmark.c /opt/ansic/bin/cc -DHPUX11 -Aa -Ae -D_HPUX_SOURCE -DMOD_PERL -DUSE_PERL_SSI -D_HPUX_SOURCE +DD64 -Ae +z -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DUSE_HSREGEX -DUSE_EXPAT -I./lib/expat-lite -DNO_DL_NEEDED
param trouble
dear list, i run into some trouble today for which i couldn't figure ailment myself nor find it googling. i got a cgi-bin dir running cgi/perl scripts under Apache::PerlRun. the directory is protected by a function in a .pm (Cartas::handler) called as a PerlInitHandler which reads some session data passed to it via GET from which it builds a cookie. when i try to read the data using CGI's param function in my Cartas::handler routine nothing is read. however, Apache::Request reads the data just fine so i figured i had everything resolved. however, when i try to read the param's in my cgi scripts via CGI's param functions nothing is returned. if i avoid reading the params with Apache::Request::param CGI::param will return the data correctly inside the CGI scripts. basically the whole thing is starting to bite its own tail and i would be very happy if anybody could give me any pointers as to why CGI won't read my data from the PerlInitHandler or after Apache::Request read them. and by the way its Apache 1.3.22 with mod_perl 1.26, perl 5.6.1 and CGI.pm version 2.80 biting his nails, tim
Re: What gives with $m-time in 1.10?
At 02:47 29.06.2002, David Dyer-Bennet wrote: It's in the doc for 1.05, not in the doc for 1.10, and I can't find any reference to it in the ChangeLog on the website, and it's not mentioned in the UPGRADE file. My application, of course, is using it, for what I thought were going to be good reasons (ability to test date-dependent stuff through the preview interface). This is Mason, right? You'll have better luck with your questions if you go to a Mason-list. See http://www.masonhq.com/resources/mailing_lists.html -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: FW: mod_perl_make error
At 16:36 28.06.2002, Garrington, Richard wrote: /opt/ansic/bin/cc -DHPUX11 -Aa -Ae -D_HPUX_SOURCE -DMOD_PERL -DUSE_PERL_SSI -D_HPUX_SOURCE +DD64 -Ae +z -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DUSE_HSREGEX -DUSE_EXPAT -I./lib/expat-lite -DNO_DL_NEEDED -D_HPUX_SOURCE +DD64 -Ae -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 +z -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DMOD_PERL\ -o httpd buildmark.o modules.o modules/perl/libperl.a modules/standard/libstandard.a main/libmain.a ./os/unix/libos.a ap/libap.a regex/libregex.a lib/expat-lite/libexpat.a `/usr/bin/perl /.cpan/build/mod_perl-1.27/src/modules/perl/ldopts ` -lm -lpthread -Wl,-E -Wl,-B,deferred +DD64 -Wl,+vnocompatwarnings -L/usr/local/lib -L/lib/pa20_64 /opt/perl5/lib/5.6.1/PA-RISC2.0-thread/auto/DynaLoader/DynaLoader.a -L/opt/perl5/lib/5.6.1/PA-RISC2.0-thread/CORE -lperl -lcl -lpthread -lnsl -lnm -ldld -lm -lc -lsec ld: Unknown input file type: regex/libregex.a Fatal error. *** Error exit code 1 This seems related to Apache and not mod_perl. You should ask at an Apache mailing list for help. Weird error though. -- Per Einar Ellefsen [EMAIL PROTECTED]
Re: Need Porting Sanity Check
Jeff Crist wrote: Excuse my typos, I just wanted to clarify I added 'use strict;' not 'use stricts;' to my code along with the -w operator (#!/usr/bin/perl -w) and I'm not seeing all the errors in my logs. Because probably your code was clean in first place. Good for you. BTW, PerlWarn On in httpd.conf is an easier way to enable warnings everywhere. __ 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: Image manipulation recommendation?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 28 June 2002 13:29, Goehring, Chuck Mr., RCI - San Diego wrote: Ryan, I couldn't get the requisites for the gd.pm and related modules to work on Windows. Although these things apparently have worked great for years on UNIX, they may have problems on Windows 2000 servers. I had to go to a purchased Java product that is accessible via a servlet to get graphs generated. Hey Chuck, Assuming you are running ActivePerl, there is a PPM for GDGraph available from the main ActiveState repository (http://www.activestate.com/PPMPackages/5.6). What sort of dependency issues are you running into? Ian -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9HZB6AjpHQQmBAUMRAlHeAKCN/wbIHMWx7w6EdkRd2QaQC19vhwCfcj9Z Ddr++uZE64ayDb3PBX4T6Gc= =99gO -END PGP SIGNATURE-
Storing and Serving Upload Images
List, I find the following situation one which arises many times for me when creating modperl applications for people. However, I always find myself thinking there is a better way to do it. I wondered if the list would like to share their thoughts on the best way. It concerns storing and serving images/media uploaded by users of the webpage. An example could be a website letting you set up your own shops to sell products. The shop maker may allow you to upload preview images of products. Assuming the product data is stored in a database, I personally wouldnt store the binary image in the databas (assuming mysql here). A solution springing to mind is to store a hash/id in the database and have a common directory (/htdocs/_previews/) which holds the pictures named after that hash/id. That way, either the modperl application can auto create the link using src=/htdocs/_previews/imageid.jpg or a lightweight handler can be used. For example /getimage?id=asdf09sd8fsa could then rewrite the uri to the real location or perform a content subrequest and let apache serve the image that way. Of course there are many solutions, but I'm wondering. Is there a best one? Any thoughts appreciated. I realise that the same situation might occur using vanilla cgi, but mod_perl provides unique ways of solving the problem, hence I post to this list. Richard.
Re: PerlTransHanlder and path_info() question
Hi, I followed Lyle's advice and moved my module down to the PerlFixupHandler phase and also added the extra logging info. However I still get, as predicted, one initial request for the correct URI and another subrequest for a URI which corresponds to the value I set the path_info to. If I don't set the path_info the subrequest disappears. So I still wonder why setting the path_info causes a subrequest to happen? Any ideas? Many thanks, Giorgos Lyle Brooks wrote: Quoting Randy Harmon ([EMAIL PROTECTED]): I have a similar problem. Yes, I'm getting a subrequest happening. Any suggestions as to why it's likely to be happening? I'm not explicitly requesting it. In my case, if the requested file is in a directory that didn't exist, this situation occurs even if I simply return DECLINED; I'd guess the default handlers are setting path_info, which for some reason is resulting in this subrequest.. RAndy This is just a general guess, as depending on your configuration alot of factors (read: modules) could be at work. If I were going to debug it (giorgos's example) further, I'd probably try to do the same operation as a FixupHandler, as opposed to a TransHandler. I say, that because the example was altering only the content generation phase (ie. PerlHander). If moving the code down the request cycle caused the subrequests went away, then you could narrow down what was generating the requestsdown to those modules registered for earlier phases. I also used the term subrequest somewhat generally, it could be from a a subrequest or an internal redirect. You could insert some code in your handler to clarify it, like this : my $r = shift; my $log = $r-server-log; $r-log-info(\n\nIncoming request); $log-debug(uri = . $r-uri); $log-debug(initial request - true) if $r-is_initial_req; $log-debug(internal redirect - true) if ($r-is_main and ! $r-is_initial_req); $log-debug(subrequest - true) unless $r-is_main; Then set your LogLevel to debug in the httpd.conf file and watch your error_log. HTH Lyle
.cgi with ModPerl
Title: Message I am setting up a server so that all my scripts have .cgi extentions. It would be nice if I could just add some directives in the httpd.conf that will have all my virtual hosts use modPerl for any files with either a .pl or a .cgi extention. The reason I prefer this method is that I have a couple scripts that I load in my httpdocs directory (the site home page is a script) So this is what I did: Commented out: AddHandler cgi-script .cgi Added the following: IfModule mod_perl.c Files ~ (\.pl|\.cgi) SetHandler perl-script PerlHandler Apache::PerlRun Options +ExecCGI allow from all PerlSendHeader On /Files/IfModule What I found is that when I only had this code only outside of the VirtualHost configurations, my test script indicated .pl was running in modPerl but .cgi wasn't. I only could get .cgi to run in mod_Perl bycopying this code inside of each of the VirtualHost configurations. Obviously I'm not an Apache config expert but one thing that also struck me strange is that while this code clearly indicates how to handle .pl and .cgi file extentions, prior to adding this, I could not find anywhere in httpd.conf where it maps .cgi files in this same way. The only code I could find is AddHandler cgi-script .cgi but shouldn't there be some additional corresponding code like PerlHandler Appache::Mod_CGI, Options +ExecCGI, etc.?? Also, how does appache know which module to use for ScriptAlias directories? I left the ScriptAlias directives in for the cgi-bin director and didn't change them to just Alias directives and it works fine but I guess that means a filematch directive overrides a ScriptAlias directive? A bit confused. Anyway, is the above method for achieving what I want an acceptable and secure/safe way to handle it? Thanks
CGI.pm and PerlRun
Title: Message I am gradually moving to mod_Perl using Apache::PerlRun instead of Apache::Registry. I am also considering switching from cgi-lib.pl to CGI.pm however I hear CGI.pm takes longer to load. Will CGI.pm automatically be cached, thereby eliminating the performance hit, by handling the scripts with Apache::PerlRun or do I have to preload the modules at server startup using PerlModule CGI; If I preload, do I have to put a PerlModule CGI; within every VirtualHost directive or just once in the httpd.conf and it will apply to all virtualhosts. And finally if I want to run CGI.pm in CGI-LIB compatibility mode, do I have to use a startup file instead or can I say: PerlModule CGI qw(:cgi-lib); I'm guessing I have to put it in a startup file?? Thanks
Re: Storing and Serving Upload Images
Richard Clarke wrote: List, I find the following situation one which arises many times for me when creating modperl applications for people. However, I always find myself thinking there is a better way to do it. I wondered if the list would like to share their thoughts on the best way. It concerns storing and serving images/media uploaded by users of the webpage. An example could be a website letting you set up your own shops to sell products. The shop maker may allow you to upload preview images of products. Assuming the product data is stored in a database, I personally wouldnt store the binary image in the databas (assuming mysql here). A solution springing to mind is to store a hash/id in the database and have a common directory (/htdocs/_previews/) which holds the pictures named after that hash/id. That way, either the modperl application can auto create the link using src=/htdocs/_previews/imageid.jpg or a lightweight handler can be used. For example /getimage?id=asdf09sd8fsa could then rewrite the uri to the real location or perform a content subrequest and let apache serve the image that way. Of course there are many solutions, but I'm wondering. Is there a best one? Any thoughts appreciated. I realise that the same situation might occur using vanilla cgi, but mod_perl provides unique ways of solving the problem, hence I post to this list. I doubt this has anything to do specifically with mod_perl , since you are talking about storage/retrieval techniques, it'll work the same for any other technology out there. Though it's an interesting topic. A *good* filesystem can serve well as database, though you should be aware of the issue with how many files you store in each directory: the more files you put into one directory the slower the access time. Modern filesystems (definitely don't use FAT based fs) implement internal hashing of file names, but you've to check the filesystem that you use for its limits. The retrieval speed significantly slows down as the search becomes linear after you pass that limit. In that case you should do your own hashing. so you map a filename 'abcdef.gif' into a/b/c/abcdef.gif (3 levels) Again how many level of hashing to use depends on how many files you plan to store and how many files you can put into each directory so the filesystem will not go to the linear lookup. Too many levels is not good since each extar sub-dir slows things down. Once you have the numbers it's easy to calculate how much levels to use Make your code transparent to the hashing function, so in the future you can easily scale and move into extra levels of hashing. Of course if you can benchmark things comparing the RDBMS' BLOB objects retrieval speed with filesystem fetch that will help to make the decision. It also depends on the caching patterns: if you have certain images being fetched frequently the kernel/filesystem will do the caching for you. Of course you can do extra caching by yourself (squid/mod_proxy/etc) but if you can get it for free from the os level it could be even better. Check also Perrin's article, but if I remember correctly it doesn't talk about this issue. http://perl.apache.org/release/docs/tutorials/apps/scale_etoys/etoys.html p.s. to hash (3 levels) you can use something like: % perl -le '$a = super_pc.gif; print join /, (split //, $a, 4)[0..2], $a' s/u/p/super_pc.gif of course you can use a more effective hashing. __ 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: CGI.pm and PerlRun
Jeff wrote: I am gradually moving to mod_Perl using Apache::PerlRun instead of Apache::Registry. I am also considering switching from cgi-lib.pl to CGI.pm however I hear CGI.pm takes longer to load. Will CGI.pm automatically be cached, thereby eliminating the performance hit, by handling the scripts with Apache::PerlRun or do I have to preload the modules at server startup using PerlModule CGI; If I preload, do I have to put a PerlModule CGI; within every VirtualHost directive or just once in the httpd.conf and it will apply to all virtualhosts. And finally if I want to run CGI.pm in CGI-LIB compatibility mode, do I have to use a startup file instead or can I say: PerlModule CGI qw(:cgi-lib); I'm guessing I have to put it in a startup file?? Jeff, you will find answers to 99% of your questions here: http://perl.apache.org/release/docs/1.0/guide/index.html __ 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: What gives with $m-time in 1.10?
Per Einar Ellefsen [EMAIL PROTECTED] writes on 29 June 2002 at 10:33:10 +0200 At 02:47 29.06.2002, David Dyer-Bennet wrote: It's in the doc for 1.05, not in the doc for 1.10, and I can't find any reference to it in the ChangeLog on the website, and it's not mentioned in the UPGRADE file. My application, of course, is using it, for what I thought were going to be good reasons (ability to test date-dependent stuff through the preview interface). This is Mason, right? You'll have better luck with your questions if you go to a Mason-list. See http://www.masonhq.com/resources/mailing_lists.html EEp! Drat. Sorry, got the lists crossed somehow. -- David Dyer-Bennet, [EMAIL PROTECTED] / New TMDA anti-spam in test John Dyer-Bennet 1915-2002 Memorial Site http://john.dyer-bennet.net Book log: http://www.dd-b.net/dd-b/Ouroboros/booknotes/ New Dragaera mailing lists, see http://dragaera.info
Re: PerlTransHanlder and path_info() question
Does your handler use Apache::Registry or Apache::PerlRun by any chance?
I did find this code snippet from the ap_add_cgi_vars() within,
the Apache core...
if (r-path_info r-path_info[0]) {
/*
* To get PATH_TRANSLATED, treat PATH_INFO as a URI path.
* Need to re-escape it for this, since the entire URI was
* un-escaped before we determined where the PATH_INFO began.
*/
request_rec *pa_req;
pa_req = ap_sub_req_lookup_uri(ap_escape_uri(r-pool, r-path_info), r);
From this it seems that, if Apache is asked to setup a CGI environment,
and if path_info is defined, then it will invoke a sub_request.
Quoting giorgos zervas ([EMAIL PROTECTED]):
Hi,
I followed Lyle's advice and moved my module down to the
PerlFixupHandler phase and also added the extra logging info.
However I still get, as predicted, one initial request for the correct
URI and another subrequest for a URI which corresponds to the value I
set the path_info to. If I don't set the path_info the subrequest
disappears. So I still wonder why setting the path_info causes a
subrequest to happen?
Any ideas?
Many thanks,
Giorgos
Lyle Brooks wrote:
Quoting Randy Harmon ([EMAIL PROTECTED]):
I have a similar problem. Yes, I'm getting a subrequest happening. Any
suggestions as to why it's likely to be happening? I'm not explicitly
requesting it.
In my case, if the requested file is in a directory that didn't exist, this
situation occurs even if I simply return DECLINED; I'd guess the default
handlers are setting path_info, which for some reason is resulting in this
subrequest..
RAndy
This is just a general guess, as depending on your configuration alot of
factors (read: modules) could be at work.
If I were going to debug it (giorgos's example) further, I'd probably try
to do the same operation as a FixupHandler, as opposed to a TransHandler.
I say, that because the example was altering only the content generation
phase (ie. PerlHander). If moving the code down the request cycle caused
the subrequests went away, then you could narrow down what was generating
the requestsdown to those modules registered for earlier phases.
I also used the term subrequest somewhat generally, it could be from a
a subrequest or an internal redirect. You could insert some code in your
handler to clarify it, like this :
my $r = shift;
my $log = $r-server-log;
$r-log-info(\n\nIncoming request);
$log-debug(uri = . $r-uri);
$log-debug(initial request - true) if $r-is_initial_req;
$log-debug(internal redirect - true)
if ($r-is_main and ! $r-is_initial_req);
$log-debug(subrequest - true) unless $r-is_main;
Then set your LogLevel to debug in the httpd.conf file and watch your
error_log.
HTH
Lyle
Re: Need Porting Sanity Check
Jeff wrote: Hey thanks for the reply. I am making progress but I have run into a problem where when I have PerlRun enabled my scripts are not see the field values being passed in the URL. I'm still using cgi-lib.pl not CGI.pm. I've never used cgi-lib.pl and you shouldn't either. That package has been deprecated for many years. By the way, do you know if PerlRun caches CGI.pm because I know otherwise it takes longer to load than the old cgi-lib.pl CGI.pm -- and any other external modules you use -- will be cached when used from PerlRun. The only thing that isn't cached is your script itself. - Perrin
IPC::Open2 under mod_perl in Mac OS X
(I'm not sure if this is a mod_perl thing of a Mac OS X bug, so I'm posting it to both lists. Redirect follow-ups as appropriate.) open2() doesn't seem to work for me when running under mod_perl in Mac OS X. Here's the test case: In /usr/local/bin/upcase #!/usr/bin/perl $buf .= $_ while(STDIN); print uc $buf; Example usage from the command line: % echo hello | upcase HELLO Now here's the CGI script that uses open2() to talk to the upcase program: #!/usr/bin/perl use strict; use CGI qw(:standard); use IPC::Open2; open2(\*READ, \*WRITE, '/usr/local/bin/upcase'); print WRITE Hello; close(WRITE); my $res; $res .= $_ while(READ); close(READ); print header(), Got: $res Running it under plain CGI shows the expected output: Got: HELLO But running it under Apache::PerlRun or Apache::Registry shows: Got: Any ideas? (Some more verbose configuration information is included below.) -John % perl -V Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=darwin, osvers=1.4, archname=darwin uname='darwin localhost 1.4 darwin kernel version 1.4: sun sep 9 15:39:59 pdt 2001; root:xnuxnu-201.obj~1release_ppc power macintosh powerpc ' config_args='-des -Dfirstmakefile=GNUmakefile -Dldflags=-flat_namespace' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef Compiler: cc='cc', ccflags ='-pipe -fno-common -DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing -I/usr/local/include', optimize='-O3', cppflags='-pipe -fno-common -DHAS_TELLDIR_PROTOTYPE -fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='Apple devkit-based CPP 6.0', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags ='-flat_namespace -L/usr/local/lib' libpth=/usr/local/lib /usr/lib libs=-lm -lc perllibs=-lm -lc libc=/System/Library/Frameworks/System.framework/System, so=dylib, useshrplib=true, libperl=libperl.dylib Dynamic Linking: dlsrc=dl_dyld.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-flat_namespace -bundle -undefined suppress -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under darwin Compiled at 01/26/02 17:02:40 %ENV: PERL_READLINE_NOWARN= INC: /System/Library/Perl/darwin /System/Library/Perl /Library/Perl/darwin /Library/Perl /Library/Perl /Network/Library/Perl/darwin /Network/Library/Perl /Network/Library/Perl . % uname -a Darwin xxx.com 5.5 Darwin Kernel Version 5.5: Thu May 30 14:51:26 PDT 2002; root:xnu/xnu-201.42.3.obj~1/RELEASE_PPC Power Macintosh powerpc Apache/1.3.23 (Darwin) mod_perl/1.26 (I've also tried this with apache 1.3.26 and got the same results) % httpd -V Server version: Apache/1.3.23 (Darwin) Server built: 02/16/02 15:51:05 Server's Module Magic Number: 19990320:11 Server compiled with -D HAVE_MMAP -D USE_MMAP_SCOREBOARD -D USE_MMAP_FILES -D HAVE_FCNTL_SERIALIZED_ACCEPT -D HAVE_FLOCK_SERIALIZED_ACCEPT -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D HTTPD_ROOT=/usr/local/apache -D SUEXEC_BIN=/usr/local/apache/bin/suexec -D DEFAULT_PIDLOG=logs/httpd.pid -D DEFAULT_SCOREBOARD=logs/httpd.scoreboard -D DEFAULT_LOCKFILE=logs/httpd.lock -D DEFAULT_XFERLOG=logs/access_log -D DEFAULT_ERRORLOG=logs/error_log -D TYPES_CONFIG_FILE=conf/mime.types -D SERVER_CONFIG_FILE=conf/httpd.conf -D ACCESS_CONFIG_FILE=conf/access.conf -D RESOURCE_CONFIG_FILE=conf/srm.conf % httpd -l Compiled-in modules: http_core.c mod_env.c mod_log_config.c mod_mime.c mod_negotiation.c mod_status.c mod_include.c mod_autoindex.c mod_dir.c mod_cgi.c mod_asis.c mod_imap.c mod_actions.c mod_userdir.c mod_alias.c mod_access.c mod_auth.c mod_setenvif.c mod_perl.c suexec: disabled; invalid wrapper /usr/local/apache/bin/suexec
Re: Need Porting Sanity Check
Jeff wrote:
So here is my strategy that I would like a sanity check from anyone on.
Go through and quickly clean up my existing code by adding use strict
and localizing all my variables (with 'my' and 'local' for special
variables) and then run is under mod_Perl using the Apache::PerlRun.
Write all my new code so that it will run under Apache::Registry and
then when I have spare time (ya right) go work on porting the older code.
PerlRun works reasonably well, and I have used it to quickly port a
large amount of legacy CGI code that made extensive use of globals.
However, it is only very slightly different from Apache::Regsitry. The
difference is that globals get cleared after each invocation, so you
don't have to worry about them retaining values.
You will not have problems with subroutines creating closures if you're
using global variables. You also won't have problems if you're passing
varaibles to subroutines. You will only have trouble if you use
lexicals in your subs that are defined outside the scope of the sub.
This is bad:
my $foo = 7;
print_foo();
sub print_foo {
print $foo\n;
}
But this is not:
my $foo = 7;
print_foo($foo);
sub print_foo {
my $foo = shift;
print $foo\n;
}
One thing that I had to change when moving to PerlRun was that the
existing scripts made extensive use of libraries that were not proper
modules, i.e. they did not declare packages, but just used a simple
require lib.pl to define a bunch of stuff in the current namespace.
That doesn't work with PerlRun or Registry. There are various
approaches for dealing with this, the quickest and worst being to change
the require file to a do file. The best is to make them actual modules.
- Perrin
Re: Another SEGV perl 5.8.0-RC2 apache 1.3.26 mod_perl 1.27
On Mon, 24 Jun 2002, Andreas J. Koenig wrote:
This stack trace is all I have. I cannot reproduce this SEGV at will,
so it will be difficult to obtain additional information. All I can do
is let the webserver run in -X mode and wait. I have no hints (yet)
what kind of request triggers it.
...
#6 0x820baa2 in PerlIO_cleanup (my_perl=0x82fc9c8) at perlio.c:2124
#7 0x810d298 in perl_destruct (my_perl=0x82fc9c8) at perl.c:490
#8 0x8099039 in perl_shutdown (s=0x82f140c, p=0x88f9c24) at mod_perl.c:294
#9 0x809b373 in perl_child_exit (s=0x82f140c, p=0x88f9c24) at mod_perl.c:958
#10 0x809afce in perl_child_exit_cleanup (data=0x88f9db4) at mod_perl.c:926
looks like a leaked PerlIO* from Request.xs, as this is happening when the
child is killed by apache (e.g. MaxRequestsPerChild reached).
patch below may cure, seems like a better approach in any case.
it is ugly here because the FILE was opened by an apache api function
which will close it when the request pool is cleared, so we must dup.
--- Request/Request.xs~ Sun Jan 20 09:27:35 2002
+++ Request/Request.xs Sat Jun 29 16:37:37 2002
-491,8 +491,13
ApacheUpload_fh(upload)
Apache::Upload upload
+PREINIT:
+int fd;
+
CODE:
-if ( ( RETVAL = PerlIO_importFILE(ApacheUpload_fh(upload),0) ) == NULL )
+fd = PerlLIO_dup(fileno(ApacheUpload_fh(upload)));
+
+if (!(RETVAL = PerlIO_fdopen(fd, r)))
XSRETURN_UNDEF;
OUTPUT:
-501,18 +506,9
CLEANUP:
if (ST(0) != PL_sv_undef) {
IO *io = GvIOn((GV*)SvRV(ST(0)));
- int fd = PerlIO_fileno(IoIFP(io));
- PerlIO *fp;
- fd = PerlLIO_dup(fd);
- if (!(fp = PerlIO_fdopen(fd, r))) {
- PerlLIO_close(fd);
- croak(fdopen failed!);
- }
if (upload-req-parsed)
- PerlIO_seek(fp, 0, 0);
-
- IoIFP(io) = fp;
+PerlIO_seek(IoIFP(io), 0, 0);
}
long
Re: IPC::Open2 under mod_perl in Mac OS X
John Siracusa wrote:
(I'm not sure if this is a mod_perl thing of a Mac OS X bug, so I'm posting
it to both lists. Redirect follow-ups as appropriate.)
open2() doesn't seem to work for me when running under mod_perl in Mac OS X.
It's not a bug in MacOSX, it simply doesn't work with mod_perl. the
piped program ('upcase' in your example) never sees any input. There are
at least two working alternatives:
1) use IPC::Run:
#!/usr/bin/perl
use strict;
use CGI qw(:standard);
use IPC::Run qw(start finish) ;
local $ENV{PATH};
print header();
my @cmd = qw(/tmp/upcase) ;
my $h = start \@cmd,
'pipe', \*IN,
'pipe', \*OUT,
'2pipe', \*ERR
or die @cmd returned $? ;
print IN Perl::Run and Barrie rule!;
close IN;
print OUT, ERR;
finish $h ;
the upcase program without any change:
#!/usr/bin/perl
$buf .= $_ while(STDIN);
print uc $buf;
2) use Apache::SubProcess:
use Apache::SubProcess ();
my $r = shift;
$r-send_http_header('text/plain');
use vars qw($input);
$input = Apache::SubProcess rules too!;
my($out, $in, $err) = $r-spawn_child(\upcase);
print $out $input;
$r-send_fd($in);
sub upcase {
my $r = shift;
$r-subprocess_env(CONTENT_LENGTH = length $input);
$r-filename(/tmp/upcase);
$r-call_exec;
}
notice that the upcase script will be different from yours in this case,
it looks like:
#!/usr/bin/perl
read STDIN, $buf, $ENV{CONTENT_LENGTH};
print uc $buf;
As this module lacks any docs, you can find them here:
http://perl.apache.org/release/docs/1.0/guide/modules.html#Apache__SubProcess
__
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
