Re: in window, mod perl 1, how to get time?
Hello there, On Sun, 8 Dec 2002, eric wrote: so how can I get the time display? in my .pl file, two lines as - my @time = time; print Right now, the elements of the time are: @time; Please read the email-etiquette document. It's on the mod_perl site at http://perl.apache.org/maillist/email-etiquette.html and it gives lots of useful tips about posting to the mod_perl list. 73, Ged.
Problem compiling mod_perl 1.27 on Windows
Hi, I'm having trouble compiling mod_perl 1.27 (with Apache 1.3.27 / Perl 5.8.0) on Windows (XP SP1 with MS VC++ 6.0 SP5). It builds fine with Perl 5.8.0 standard sources, but I'm just trying to upgrade my Perl to the slightly patched sources that ActivePerl Build 804 uses. I've built Perl from these new sources with the same build options that I used before for the standard source build (no threading, and Perl's malloc). (The output of Perl -V is at the bottom of this mail.) I run the following commands to build mod_perl: perl Makefile.PL APACHE_SRC=C:/apache INSTALL_DLL=C:/apache/modules EAPI nmake The first command runs fine, but the second has the following error: Apache.xs(1963) : error C2115: '=' : incompatible types The line referred to by this error is: statcache = r-finfo; I've no idea why this should be causing a problem with the new Perl. If I switch the Perl that I'm building against back to the standard 5.8.0 (by simply re-naming directories) and then re-run the nmake command above then mod_perl compiles and links with no errors. Can anyone shed any light on this? - Steve = Summary of my perl5 (revision 5 version 8 subversion 0) configuration: Platform: osname=MSWin32, osvers=4.0, archname=MSWin32-x86-perlio uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=y, bincompat5005=undef Compiler: cc='cl', ccflags ='-nologo -Gf -W3 -MD -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DUSE_PERLIO -DPERL_MSVCRT_READFIX', optimize='-MD -DNDEBUG -O1', cppflags='-DWIN32' ccversion='', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='link', ldflags ='-nologo -nodefaultlib -release -libpath:C:\perl5\lib\CORE -machine:x86' libpth=C:\PROGRA~1\MICROS~2\VC98\lib C:\openssl\lib libs=libeay32.lib oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib perllibs=libeay32.lib oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib gnulibc_version='undef' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -release -libpath:C:\perl5\lib\CORE -machine:x86' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under MSWin32 Compiled at Dec 13 2002 08:42:43 @INC: C:/perl5/lib C:/perl5/site/lib .
[mp1.0] DESTROY doesn't honor read-only flag (possible bug).
Hello,
We began to encounter some odd segfaults, and after poking through
mod_perl believed that we have found the problem. The DESTROY() function
in Table.xs is not honoring the read only flag in self, which would seem
to be a bug.
For reasons we are still trying to discover (;), it's being called and
asked to delete some sort of shared, read-only object (probably belonging
to Apache?). We only saw this happen intermittently, and under very high
load.
The attached patch was written by Erik Arneson ([EMAIL PROTECTED]).
So, is this an actual bug or is it more likely that we're in some way
horribly abusing mod_perl (or is it both ;)?
Thank you all very much,
_Jesse Williamson ;-};
--- apache_1.3.26/mod_perl-1.27/src/modules/perl/Table.xs.table Tue Dec 10 11:55:24
2002
+++ apache_1.3.26/mod_perl-1.27/src/modules/perl/Table.xs Tue Dec 10 11:57:55
+2002
@@ -112,13 +112,19 @@
PREINIT:
Apache__Table tab;
CODE:
-tab = (Apache__Table)hvrv2table(self);
-if(SvROK(self) SvTYPE(SvRV(self)) == SVt_PVHV)
-safefree(tab);
+if (!SvREADONLY(self)) {
+tab = (Apache__Table)hvrv2table(self);
+if(SvROK(self) SvTYPE(SvRV(self)) == SVt_PVHV)
+safefree(tab);
+}
+else {
+fprintf(stderr, Apache::Table is trying to free READONLY SV at %p\n, self);
+fflush(stderr);
+}
void
FETCH(self, key)
Apache::Table self
const char *key
RE: Perl Cookbook modperl chapter
-Original Message- Grant McLean wrote: Nathan Torkington wrote: Current recipe list: [gnat:~] grep head1 Ora/pcb2/ch21.pod =head1 Introduction =head1 Authenticating in mod_perl =head1 Setting Cookies in mod_perl =head1 Accessing Cookie Values from mod_perl =head1 Redirecting the Browser from mod_perl =head1 Interrogating Headers in mod_perl Handlers =head1 Accessing Form Parameters from mod_perl =head1 Receiving Uploaded Files in mod_perl Database persistence is an important topic but it's hard to say whether one directive ... PerlModule Apache::DBI ... constitutes a 'recipe' I agree that database persistence is an important topic and should be included in the perl Cookbook. However, Apache::DBI is not always the answer. Example: I currently have a need to use database persistence for an Ingres Database. So I installed the DBD::Ingres Module and attempted to use Apache::DBI. Needless to asy it did not work :-( After much searching/posting I got my answer. Henrik Tougaard wrote: (from comp.databases.ingres) I wouldn't bet on Apache::DBi working with DBD::Ingres! Reason: cached statementhandles are not implemented (currently) in DBD::Ingres and Apache::DBI uses them. (It's on my todo list, but not scheduled right now - i seem to have run out of tuits). I assume that the only way of getting permanent connections is to have another process hold them for you - but the hassle of accessing the connections would be so great, that it might be just as easy to avoid CGI entirely and go straight for mod_perl. OK, so now what? This type of situation could be discussed then talk about the Apache::DBI module. Just my 2 cents Ron Hill
Re: Perl Cookbook modperl chapter
Hill, Ronald wrote: -Original Message- Grant McLean wrote: Nathan Torkington wrote: Current recipe list: [gnat:~] grep head1 Ora/pcb2/ch21.pod =head1 Introduction =head1 Authenticating in mod_perl =head1 Setting Cookies in mod_perl =head1 Accessing Cookie Values from mod_perl =head1 Redirecting the Browser from mod_perl =head1 Interrogating Headers in mod_perl Handlers =head1 Accessing Form Parameters from mod_perl =head1 Receiving Uploaded Files in mod_perl Database persistence is an important topic but it's hard to say whether one directive ... PerlModule Apache::DBI ... constitutes a 'recipe' I agree that database persistence is an important topic and should be included in the perl Cookbook. However, Apache::DBI is not always the answer. Example: I currently have a need to use database persistence for an Ingres Database. So I installed the DBD::Ingres Module and attempted to use Apache::DBI. Needless to asy it did not work :-( After much searching/posting I got my answer. Henrik Tougaard wrote: (from comp.databases.ingres) I wouldn't bet on Apache::DBi working with DBD::Ingres! Reason: cached statementhandles are not implemented (currently) in DBD::Ingres and Apache::DBI uses them. (It's on my todo list, but not scheduled right now - i seem to have run out of tuits). I assume that the only way of getting permanent connections is to have another process hold them for you - but the hassle of accessing the connections would be so great, that it might be just as easy to avoid CGI entirely and go straight for mod_perl. OK, so now what? This type of situation could be discussed then talk about the Apache::DBI module. It's much simpler than that. You need two sentences: 1) under mod_perl, globals remember their values from the previous request, so you can cache the connection with: $dbh ||= myconnect(); 2) If you rdbms supports cached statement handles (which most do), you can use Apache::DBI which caches database connection without needing to change any of your code. But of course I agree that it's a good idea to mention this topic. I suggest that many other topics are to be mentioned but replace discussions with pointers to the relevant chapters of the mod_perl books and online documentation. So newbies, know what to look for. It's not obvious that database connections can be cached. __ 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
When perl is not quite fast enough
While reading Mark Fowler excelent Perl Advent Calendar (http://www.perladvent.org/2002/) 6th entry: http://www.perladvent.org/2002/6th/, in the references section I've noticed a link to Nicolas Clark's notes from his YAPC::EU::2002 presentation, on how to make your perl code faster: http://www.ccl4.org/~nick/P/Fast_Enough/ It's a very good read, and very relevant to us mod_perl users, who always want to have their code run faster. I especially liked it since it's very concise and gives you ideas of areas to explore. Certain things Nicolas talks about are already covered in detail in the mod_perl documentation. BTW, most other things mentioned in his notes are in the performance section of our upcoming mod_perl book (ora promises to get the book on the shelves in feb-mar next year). Me thinking to ask Nicolas to contribute these notes to our tutorial section (http://perl.apache.org/docs/tutorials/) and if possible to add some more meat to the original notes. If you remember our evil plan was to host at perl.apache.org interesting tutorials, relevant to mod_perl developers, but which are of interest to non-mod_perl developers too, thus bringing them to our site and hopefully getting them interested in mod_perl. Nicolas's doc, looks like a good bite ;) __ 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: Perl Cookbook modperl chapter
Stas Bekman wrote: Hill, Ronald wrote: It's much simpler than that. You need two sentences: 1) under mod_perl, globals remember their values from the previous request, so you can cache the connection with: $dbh ||= myconnect(); But Apache::DBI implements pinging (immediate or timing based) which is much superior to this. Some databases drop connection otherwise. Or consider the case where the database goes down and then all the $dbh becomes invalid. Apache::DBI would recover gracefully I think. But the above method wouldn't. 2) If you rdbms supports cached statement handles (which most do), you can use Apache::DBI which caches database connection without needing to change any of your code. I am not aware of Apache::DBI caching statement handles. Are you sure that Apache::DBI does this? Or is it a side effect of caching the database handle. If it is the latter, then then caching with #1 above would not solve the problem. If it is the former, perhaps someone can add a global setup variable to Apache::DBI to turn this feature off. eg $Apache::DBI::statement_handle_caching = 0; # default = 1 But of course I agree that it's a good idea to mention this topic. I suggest that many other topics are to be mentioned but replace discussions with pointers to the relevant chapters of the mod_perl books and online documentation. So newbies, know what to look for. It's not obvious that database connections can be cached. __ 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: Perl Cookbook modperl chapter
Gunther Birznieks wrote: Stas Bekman wrote: Hill, Ronald wrote: It's much simpler than that. You need two sentences: 1) under mod_perl, globals remember their values from the previous request, so you can cache the connection with: $dbh ||= myconnect(); But Apache::DBI implements pinging (immediate or timing based) which is much superior to this. Some databases drop connection otherwise. Or consider the case where the database goes down and then all the $dbh becomes invalid. Apache::DBI would recover gracefully I think. But the above method wouldn't. You are correct. 2) If you rdbms supports cached statement handles (which most do), you can use Apache::DBI which caches database connection without needing to change any of your code. I am not aware of Apache::DBI caching statement handles. Are you sure that Apache::DBI does this? Ah, sorry, wrong copy-n-paste. i wanted to say connection. Thanks for correcting me! Or is it a side effect of caching the database handle. If it is the latter, then then caching with #1 above would not solve the problem. If it is the former, perhaps someone can add a global setup variable to Apache::DBI to turn this feature off. eg $Apache::DBI::statement_handle_caching = 0; # default = 1 __ 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
windows and apache/mod_perl?
Is it worth installing apache 1.x and mod_perl 1.x on windows if apache2/mod_perl2/perl5.8 run on windows? Thanks
Re: When perl is not quite fast enough
Stas Bekman [EMAIL PROTECTED] writes: [...] Me thinking to ask Nicolas to contribute these notes to our tutorial section (http://perl.apache.org/docs/tutorials/) and if possible to add some more meat to the original notes. If you remember our evil plan was to host at perl.apache.org interesting tutorials, relevant to mod_perl developers, but which are of interest to non-mod_perl developers too, thus bringing them to our site and hopefully getting them interested in mod_perl. Nicolas's doc, looks like a good bite ;) Great idea, Stas. His comments definitely should be part of the mod_perl canon; those notes present *the right approach* to optimization. -- Joe Schaefer
Re: Problem compiling mod_perl 1.27 on Windows
On Mon, 16 Dec 2002, Steve Hay wrote: Hi, I'm having trouble compiling mod_perl 1.27 (with Apache 1.3.27 / Perl 5.8.0) on Windows (XP SP1 with MS VC++ 6.0 SP5). It builds fine with Perl 5.8.0 standard sources, but I'm just trying to upgrade my Perl to the slightly patched sources that ActivePerl Build 804 uses. I've built Perl from these new sources with the same build options that I used before for the standard source build (no threading, and Perl's malloc). (The output of Perl -V is at the bottom of this mail.) I run the following commands to build mod_perl: perl Makefile.PL APACHE_SRC=C:/apache INSTALL_DLL=C:/apache/modules EAPI nmake The first command runs fine, but the second has the following error: Apache.xs(1963) : error C2115: '=' : incompatible types The line referred to by this error is: statcache = r-finfo; I've no idea why this should be causing a problem with the new Perl. If I switch the Perl that I'm building against back to the standard 5.8.0 (by simply re-naming directories) and then re-run the nmake command above then mod_perl compiles and links with no errors. Can anyone shed any light on this? - Steve [ .. ] Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES I've found the same thing - I believe it's because of the USE_LARGE_FILES support that ActivePerl 8xx has enabled, and this runs into a conflict with the standard Win32 apache-1 which doesn't have such support (in the above, statcache is from the Perl side, and r-finfo is from Apache). This is still being looked into ... One possibility is to recompile Apache with large_file support, but this is non-trivial. And since the bulk of Win32 development on Apache is going into Apache-2, it may be hard to get an Apache developer to look at this. By the way, mod_perl-2 (for use with Apache2) compiles fine with the ActivePerl sources. -- best regards, randy kobes
Access to ap_send_fd_length in 1.0
I have a client for whom I manage documents, some of which are in pdf format. The documents are not in the web tree, and are served based on custom access etc., and some are encrypted on the files system. I am successfully do all this, and ultimately use send_fd to send the file(s). The client has noticed that through the managed process, the time to view the pdf is longer than viewing the same file through the default handler. I have discovered that this is most likely due to the fact that Apache is byteserving the file, allowing the first page to be viewed even though the complete file has not been downloaded. The complete time to download between the default handler and my handler are quite close, but the document comes up for partial view much quicker with the default handler. I have been able to use Apache::File to modify my handler to recognize when a byteserving request has come in ( using ap_set_byterange), and access the ap_each_byterange call to decode the header. However, it does not seem like the ap_send_fd_length is mod_perl accessible. Is there any issue with adding access to this API function? Also, will I have a problem setting the PARTIAL_CONTENT response? With the clients encrypted documents, I have the documents in memory only. I would like to use the send_fb/send_fb_length call in a similar fashion. I haven't done any XS/guts type programming, so I'm hoping this will be a relatively simple task. Thanks for any pointers, Tom Murphy
Re: Problem compiling mod_perl 1.27 on Windows
Randy Kobes wrote:
On Mon, 16 Dec 2002, Steve Hay wrote:
I'm having trouble compiling mod_perl 1.27 (with Apache 1.3.27 / Perl
5.8.0) on Windows (XP SP1 with MS VC++ 6.0 SP5).
It builds fine with Perl 5.8.0 standard sources, but I'm just trying to
upgrade my Perl to the slightly patched sources that ActivePerl Build
804 uses. I've built Perl from these new sources with the same build
options that I used before for the standard source build (no threading,
and Perl's malloc). (The output of Perl -V is at the bottom of this
mail.)
[ .. ]
Characteristics of this binary (from libperl):
Compile-time options: USE_LARGE_FILES
I've found the same thing - I believe it's because of the
USE_LARGE_FILES support that ActivePerl 8xx has enabled, and this
runs into a conflict with the standard Win32 apache-1 which
doesn't have such support (in the above, statcache is from the
Perl side, and r-finfo is from Apache). This is still being
looked into ...
One possibility is to recompile Apache with large_file support,
but this is non-trivial. And since the bulk of Win32 development
on Apache is going into Apache-2, it may be hard to get an Apache
developer to look at this.
Looking at mod_perl (1.27)'s Makefile.PL I see that there is a
uselargefiles_check() routine that originally warned about conflicts,
but now (as of 1.27, according to the Changes file) automatically sets
PERL_USELARGEFILES=0 to try to avert disaster. But the only difference
that this seems to make is to stop Perl's $Config{ccflags} from being
appended to PERL_EXTRA_CFLAGS. However, my Perl (804)'s
$Config{ccflags} doesn't mention anything to do with large_files, so
it's hardly surprising that disaster is not averted (if this is indeed
the problem).
Is there some other way, for Win32, to achieve what the
PERL_USELARGEFILES=0 hack tried to do?
I also see that the warning that was originally output by
uselargefiles_check() suggested re-building Apache with large_files
support by simply specifying a couple of extra defines. I take it from
what you're saying that it isn't quite as trivial as that on Win32?
By the way, mod_perl-2 (for use with Apache2) compiles fine with
the ActivePerl sources.
I've been reluctant to use mod_perl 2 for anything more than testing
purposes yet because its current version number (1.99_07) doesn't fill
me with confidence that it's sufficiently stable. The mod_perl setup
that I'm trying to build is destined for a production environment, so
I'd rather stick to more tried and tested things for now.
I would be interested to hear how stable people think mod_perl 2
currently is on Win32.
- Steve
Re: Access to ap_send_fd_length in 1.0
Tom Murphy wrote: I have a client for whom I manage documents, some of which are in pdf format. The documents are not in the web tree, and are served based on custom access etc., and some are encrypted on the files system. I am successfully do all this, and ultimately use send_fd to send the file(s). The client has noticed that through the managed process, the time to view the pdf is longer than viewing the same file through the default handler. I have discovered that this is most likely due to the fact that Apache is byteserving the file, allowing the first page to be viewed even though the complete file has not been downloaded. The complete time to download between the default handler and my handler are quite close, but the document comes up for partial view much quicker with the default handler. I have been able to use Apache::File to modify my handler to recognize when a byteserving request has come in ( using ap_set_byterange), and access the ap_each_byterange call to decode the header. However, it does not seem like the ap_send_fd_length is mod_perl accessible. $r-send_fd($fh, $length); see recipe 6.3 in the mod_perl developer's cookbook, but that's about all there is to the call. recipe 6.7 explains byteserving in general, but it seems you've already seen the appropriate methods in Apache::File. Is there any issue with adding access to this API function? no :) Also, will I have a problem setting the PARTIAL_CONTENT response? you shouldn't if you use the proper series of API calls - order is important. see http://www.modperlcookbook.org/code/ch06/Cookbook/SendAnyDoc.pm for an example. With the clients encrypted documents, I have the documents in memory only. I would like to use the send_fb/send_fb_length call in a similar fashion. I haven't done any XS/guts type programming, so I'm hoping this will be a relatively simple task. it's relatively simple to create a subclass Apache that adds whatever ap_ method you want to $r. there are a few examples in the cookbook, or you can see some materials in the presentation I just gave at ApacheCon http://www.modperlcookbook.org/~geoff/slides/ApacheCon/oo-mod_perl-printable.ppt.gz most of the examples can be found someplace under http://www.modperlcookbook.org/~geoff/modules/ HTH --Geoff
Re: Problem compiling mod_perl 1.27 on Windows
On Mon, 16 Dec 2002, Steve Hay wrote:
Randy Kobes wrote:
I've found the same thing - I believe it's because of the
USE_LARGE_FILES support that ActivePerl 8xx has enabled, and this
runs into a conflict with the standard Win32 apache-1 which
doesn't have such support (in the above, statcache is from the
Perl side, and r-finfo is from Apache). This is still being
looked into ...
One possibility is to recompile Apache with large_file support,
but this is non-trivial. And since the bulk of Win32 development
on Apache is going into Apache-2, it may be hard to get an Apache
developer to look at this.
Looking at mod_perl (1.27)'s Makefile.PL I see that there is a
uselargefiles_check() routine that originally warned about conflicts,
but now (as of 1.27, according to the Changes file) automatically sets
PERL_USELARGEFILES=0 to try to avert disaster. But the only difference
that this seems to make is to stop Perl's $Config{ccflags} from being
appended to PERL_EXTRA_CFLAGS. However, my Perl (804)'s
$Config{ccflags} doesn't mention anything to do with large_files, so
it's hardly surprising that disaster is not averted (if this is indeed
the problem).
That's true - Perl's ccflags don't mention USE_LARGE_FILES; it
only gets mentioned in the compile-time options.
Is there some other way, for Win32, to achieve what the
PERL_USELARGEFILES=0 hack tried to do?
This seems hard to do without recompiling either the standard
Apache sources (to enable large_files support) or else the
standard ActivePerl 8xx sources (to disable large_files support).
One possibility is to define one's own statcache (presently
defined in the header files under /Perl/lib/CORE/) as is defined
in a Win32 Perl without large_files support. That may get around
the problem in Apache.xs about incompatible types between
statcache and r-finfo, but this might lead to other problems
later.
I also see that the warning that was originally output by
uselargefiles_check() suggested re-building Apache with
large_files support by simply specifying a couple of extra
defines. I take it from what you're saying that it isn't quite
as trivial as that on Win32?
I tried just adding a couple of extra defines in compiling apache
- this starts a series of error messages in various C files about
incompatibilities, which then leads to having to put in a bunch
of #ifdef ... statemements. Ultimately this probably could be
worked out, but I'd be very uncomfortable using such a hacked
version without some official Apache support.
By the way, mod_perl-2 (for use with Apache2) compiles fine with
the ActivePerl sources.
I've been reluctant to use mod_perl 2 for anything more than testing
purposes yet because its current version number (1.99_07) doesn't fill
me with confidence that it's sufficiently stable. The mod_perl setup
that I'm trying to build is destined for a production environment, so
I'd rather stick to more tried and tested things for now.
I would be interested to hear how stable people think mod_perl 2
currently is on Win32.
That would be interesting
--
best regards,
randy
Re: windows and apache/mod_perl?
On Mon, 16 Dec 2002, Paul Simon wrote: Is it worth installing apache 1.x and mod_perl 1.x on windows if apache2/mod_perl2/perl5.8 run on windows? I guess it depends on what one is using it for ... For a development/learning system, the performance enhancements with apache2/modperl2 probably outweigh the disadvantages of using the more stable/tested apache1/modperl1 combination. But for a production system, it may be non-trivial to upgrade; in particular, many Apache::* modules may need either mod_perl-2's compatibility mode or some (small, or perhaps large) changes to work with mod_perl-2. -- best regards, randy kobes
Re: SSI Not Working Apache
Martin Kuria wrote: mod_include is not included please do advice what do I need to have ssi to work please do help Hi Martin, This list is not for general Apache configuration questions. Please see http://httpd.apache.org/lists.html to find a more appropriate list to ask your question on. - Perrin
RE: Cookie-free authentication
On Fri, 13 Dec 2002 20:19:55 -0800 (PST), Bill Moseley wrote: Hi Bill On Sat, 14 Dec 2002, Ron Savage wrote: Under Apache V 1/Perl 5.6.0 I could not get the Apache::AuthCookieURL option working which munged URLs without requiring cookies. I thought the problem was that Apache::AuthCookie was redirecting to your login scrip on logout instead of displaying your logout page. Yes, this is one problem. PS My email/internet access at the office has been discontinued while I'm 'between contracts'. -- Cheers Ron Savage, [EMAIL PROTECTED] on 17/12/2002 http://savage.net.au/index.html
We need help from mod_perl users with technical expertise in non-mainstreamOSs
Here at the list we have a rather sucky trend in the last year or so. Those folks who report problems that they have on platforms that aren't *BSD, Linux and Win32 mostly get unasnwered. Doug, who seems to know about everything, used to respond to those souls, but nowadays he's too busy with real work. We have plenty of folks who are kind enough to help others with Linux, BSD flavors and Win32. So we are all dandy on these platforms. So, my big request is to all the folks on the other platforms, whose users don't get their problems resolved here. If somebody posts a problem that happens on the platform that you use, please try to help that person, even if you don't consider yourself an expert. Many times a participation in the person's quest helps him to find the way on its own. What bugs most people is the silence. Also if you know somebody who may know the answer but not on the list, please take the initiative and try to kindly ask that person to help. And who knows may be he will enjoy to help and do that in the future as well. Please, stop lurking in the shades, but try to help when you see that nobody else does. Especially if you were helped here before. Remember that you have to give back, if everybody becomes a leech there will be no blood left. Also remember that helping others is addictive, you just need to start doing that. Also remember that we all do mistakes. And we aren't experts in all fields. So if your answer is incorrect, it's not a big problem, since surprisingly, someone, who ignores the original question in first place, immediately posts to correct you. Don't feel bad about that, since you've just learned something. On the opposite feel good about your follow-up, because you tried to help. So, if my rant wakes anybody out there on SunOS, can you please try to figure out what the problem is with Kenny Smith's report: http://mathforum.org/epigone/modperl/sleikrigroo There are many earlier questions that went unanswered, just go to http://mathforum.org/epigone/modperl and see which posts have no followup, and try to help. It's better late, then never. __ 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
