perl section does not override conf default
Hi
I have an httpd.conf like this for what concerns icons
(this is default apache conf)
#Alias /icons/ c:/apback/icons/
#Directory c:/apback/icons
#Options Indexes MultiViews
#AllowOverride None
#Order allow,deny
#Allow from all
#/Directory
later in the conf I have a perl section redefining the above :
[...]
push Alias, ['/icons/'=$MY::basePath/icons/];
$Directory{$MY::basePath.'/icons'}={
Options='Indexes Multiviews',
AllowOverride='None',
Order='allow,deny',
Allow='from all'
};
$Location{/icons/}=
{
SetHandler='default-handler',
};
the problem is that
if I do not comment out apache default conf section,
handler is well reset to default handler but the alias
and directory directive are not overriden by the perl section
so icons are sought in default c:/apback/icons directory
instead of the special one indicated by $MYbasepath.
is it normal ?
thanks
pascal
Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,13
/mn) ; tél : 08 92 68 13 50 (0,34/mn)
RE: CGI Forms Problems (Getting Old Params)
It's CGI.pm
It caches your variables for your convenience/headaches.
Try this...
my $cgi = new CGI();
$cgi-textfield(-override=1,-name=namen,-value=priceless);
-Original Message-
From: Shannon Appelcline [mailto:[EMAIL PROTECTED]]
Sent: Saturday, September 28, 2002 3:03 PM
To: [EMAIL PROTECTED]
Subject: CGI Forms Problems (Getting Old Params)
Yesterday I ported a few thousand lines of code I'd been working on
over to Perl. It was quite a bit of work getting all of the strict
stuff correct and then fighting with the modules-do-not-reload
problem, but it's now mostly dealt with, and my code's much cleaner
and more modularized. (Huzzah.)
Unfortunately I've been continuing to have one program that I can't
figure out. Somehow, my information being submitted through forms
sometimes reverts to old data after I've clicked Submit and before
it's processed.
Now, I've read through much of the mod_perl documents, FAQs, etc.,
and I understand the general shape of *why* this happens. It's the
result of mod_perl keeping the perl modules, and thus the variables,
in memory. When I hit a server that's already been loaded, I get
incorrect results. What I don't understand is *how* it's happening in
this specific case, because I'm being very careful about clearly
setting my variables each time through.
There must be some aspect of how mod_perl works that I'm missing. I'm
hoping someone here can (1) tell me what I'm doing wrong in this
specific case and (2) tell me where my mental map is incorrect.
Anyway, here we go.
I start off with a simple index.cgi that I've made extremely short to
avoid the issue of nested subroutines. It has a require:
--
$main::filePath = /var/www/skotos/myskotos;
require ${main::filePath}/modules/lib/mylib.pm;
--
From that required library, I set my $cgi variable:
--
package mylib;
use CGI;
use CGI::Pretty qw( :html3 );
$mylib::cgi = new CGI;
--
It's a global variable, but that seems entirely appropriate for
something that's used in nearly every function. And, it gets
explicitly set every time the program is run.
Back in the original index.cgi, I have the problems when it's called
to process form information. Here's that particular segment of code:
--
require ${main::filePath}/modules/web/myedit.pm;
my $action = $mylib::cgi-param('action');
$main::pageNumber = $mylib::cgi-param('pageNumber');
$main::contentType = $mylib::cgi-param('contentType');
if ($action eq editpage) {
myedit::ProcessEditPage();
} elsif ($action eq editcontent) {
myedit::ProcessEditContent();
}
--
And, pretty much ANY of those parameters that I call in from $cgi can
come up wrong. Both the local variables defined by my ($action) and
the global variables set to $main ($pageNumber, $contentType) ...
which tells me that the problem is back in that $cgi reference.
But why?
Can I not set variables which might change down in modules? That
would seem grossly limiting if so, given that I've moved everything
to modules in order to avoid the nested subroutine problems.
Or am I missing something else?
I should mention, that out of extreme paranoia at this point I'm even
trying to undef $cgi when I'm done, to no effect.
--
END {
$mylib::dbh-disconnect if $mylib::dbh;
undef $mylib::cgi;
}
--
Help?
Shannon
--
Shannon
--
You met me at a very strange time in my life. --_Fight Club_
--
This message is intended only for the personal and confidential use of the designated
recipient(s) named above. If you are not the intended recipient of this message you
are hereby notified that any review, dissemination, distribution or copying of this
message is strictly prohibited. This communication is for information purposes only
and should not be regarded as an offer to sell or as a solicitation of an offer to buy
any financial product, an official confirmation of any transaction, or as an official
statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or
error-free. Therefore, we do not represent that this information is complete or
accurate and it should not be relied upon as such. All information is subject to
change without notice.
Re: UTF8 character issue with Apache::Request?
Confirmed, but its browser dependant. IE on Mac OS X sends the file but munges the filename. So they file arrives fine but with the wrong name. Mozilla on Mac OS X doesnt even send the file. Still waiting for results with windows systems buth Eng and J. John- On 28 Sep 2002 23:02:59 -0400 Joe Schaefer [EMAIL PROTECTED] wrote: Peter Bi [EMAIL PROTECTED] writes: Please take a serious look. I did, and I suspect this problem is caused by OP's client/browser failing to open the file with the Kanji filename, so it might be sending an empty file with the default enctype instead. There were several related reports in the mailing list during the months: Apache::Request might not handle double-bytes or utf8 correctly. Or it may be due to the C library. You seem to know something about this issue. However, this is the first time I've seen utf8 discussed in relation to Apache::Request on this list. I've tried a few dozen links from google (utf8 Apache::Request), and I've searched the epigone archives for this list. I wasn't able to find a single related report. A reference url, a test case, or a better still, a patch, would be considerably more helpful than sending me on a wild goose chase. -- Joe Schaefer
document contains no data errors (with mod_ssl)
i have a working version of apache 1.3.26 with mod_perl 1.27, no problems.. i installed another apache 1.3.26 build with openssl 0.9.6g, mod_ssl 2.8.10-1.3.26, and mod_perl 1.27, and am receiving document contains no data error messages quite frequently. I tried restarting the newly installed apache without mod_ssl enabled, but I still get the errors. I have fine tuned apache exactly how my original version was tuned, and am still having these problems. Any suggestions? __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com
Re: document contains no data errors (with mod_ssl)
incidentally, i noticed i am getting a lot of these errors in the error_log: Out of memory! Callback called exit. --- Anthony E. [EMAIL PROTECTED] wrote: i have a working version of apache 1.3.26 with mod_perl 1.27, no problems.. i installed another apache 1.3.26 build with openssl 0.9.6g, mod_ssl 2.8.10-1.3.26, and mod_perl 1.27, and am receiving document contains no data error messages quite frequently. I tried restarting the newly installed apache without mod_ssl enabled, but I still get the errors. I have fine tuned apache exactly how my original version was tuned, and am still having these problems. Any suggestions? __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com
problems with sessions and upgrading
OLD STUFF: redhat 5.2, 2.0.36 kernel, 1.3.6 apache, 1.21 mod_perl, perl 5.005_02, apache session 1.04 and a storable of 0.63, embperl 1.2.b10, file system sessions and locking data. NEW STUFF: redhat 5.2, 2.0.36 kernel, 1.3.26 apache, 1.27 mod_perl, perl 5.6.1, apache session 1.54, apache sessionX 2.00b3, storable of 2.05, embperl 1.3.4, file system sessions and locking data.. i am trying to update my server to the lastest and greatest from the oldest and moldiest. the data in my current file based session system is very important to me, and i cannot just dump it and create a new pristine session system. i am having two separate problems. 1) the sessions keys for the new sessions are twice as long as the old ones. generally, this is a good thing, but i am concerned that the old session data will not get read when the cookie is submitted. will the old sessions get read and reused, read and new ones created, totally ignored? obviously i would test this, but can't because of problem #2. 2) i cannot read the old session data with the new session modules. when i try to read them by doing: /usr/local/httpd/perl561/bin/perl -e 'use Storable qw(thaw); use Data::Dumper; open(FIL,/u3/sessions/01aef30dddbf0747) || die file; undef $/; my $frozen=FIL; my $thawed=thaw($frozen); print Dumper \$thawed;' yields the following error message: Storable binary image v56.115 more recent than I am (v2.5) at blib/lib/Storable.pm (autosplit into blib/lib/auto/Storable/thaw.al) line 364, FIL chunk 1, at -e line 1 i already tried googling and posting to perl5-porters. i did not find help in either arena. if anyone has a clue on this i would appreciate it. below are dumps of perl -V as well as a dump of the initial part of the session data. thanks in advance! -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/ - snip - # perl -V Summary of my perl5 (5.0 patchlevel 5 subversion 2) configuration: Platform: osname=linux, osvers=2.0.36, archname=i686-linux uname='linux www.genwax.com 2.0.36 #1 mon dec 7 03:44:15 pst 1998 i686 unknown ' hint=previous, useposix=true, d_sigaction=define usethreads=undef useperlio=undef d_sfio=undef Compiler: cc='cc', optimize='-O2', gccversion=2.7.2.3 cppflags='-Dbool=char -DHAS_BOOL' ccflags ='-Dbool=char -DHAS_BOOL' stdchar='char', d_stdstdio=define, usevfork=false intsize=4, longsize=4, ptrsize=4, doublesize=8 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt libc=, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Built under linux Compiled at Nov 16 1999 11:24:18 @INC: /usr/lib/perl5/5.00502/i686-linux /usr/lib/perl5/5.00502 /usr/lib/perl5/site_perl/5.005/i686-linux /usr/lib/perl5/site_perl/5.005 - snip - # /usr/local/httpd/perl561/bin/perl -V Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration: Platform: osname=linux, osvers=2.0.36, archname=i686-linux uname='linux www.genwax.com 2.0.36 #1 mon dec 7 03:44:15 pst 1998 i686 unknown ' config_args='-Dprefix=/usr/local/httpd/perl561' 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 =' -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64', optimize='-O2', cppflags='' ccversion='', gccversion='2.7.2.3', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=4 alignbytes=4, usemymalloc=n, prototype=define Linker and Libraries: ld='cc', ldflags =' -L/usr/local/lib' libpth=/usr/local/lib /lib /usr/lib libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt -lutil perllibs=-lnsl -ldl -lm -lc -lposix -lcrypt -lutil libc=/lib/libc-2.0.7.so, so=so, useshrplib=false, libperl=libperl.a Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic' cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under linux Compiled at Sep 18 2002 22:25:33 @INC: /usr/local/httpd/perl561/lib/5.6.1/i686-linux /usr/local/httpd/perl561/lib/5.6.1
Re: problems with sessions and upgrading
OLD STUFF: redhat 5.2, 2.0.36 kernel, 1.3.6 apache, 1.21 mod_perl, perl 5.005_02, apache session 1.04 and a storable of 0.63, embperl 1.2.b10, file system sessions and locking data. NEW STUFF: redhat 5.2, 2.0.36 kernel, 1.3.26 apache, 1.27 mod_perl, perl 5.6.1, apache session 1.54, apache sessionX 2.00b3, storable of 2.05, embperl 1.3.4, file system sessions and locking data.. ... yields the following error message: Storable binary image v56.115 more recent than I am (v2.5) at blib/lib/Storable.pm (autosplit into blib/lib/auto/Storable/thaw.al) line 364, FIL chunk 1, at -e line 1 Did you try to install the old storable into the new Perl? If this works you could convert it to some other format (e.g. Data::Dumper), install the new storeable and put the session data back. Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 -
