Re: libapreq-1.1 Release Candidate 1
PowerBook Ti 667 Rev1 (1GB RAM 30GB HD)
OS X 10.2
Apache 1.3.27 installed at Apple default (custom build w/ mod_perl 1.27)
Apache 2.0.43 installed at /usr/local/apache2
Ran configure then make and got the error:
cpp-precomp: warning: errors
during smart preprocessing, retrying in basic
mode
make[1]: *** [apache_cookie.lo] Error 1
make: *** [all-recursive] Error 1
Gory details follows:
[honeycrisp:~/src/httpd-apreq] em% ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets ${MAKE}... yes
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc
checking build system type... powerpc-apple-darwin6.2
checking host system type... powerpc-apple-darwin6.2
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... no
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -p
checking whether ln -s works... yes
checking how to recognise dependant libraries... file_magic Mach-O
dynamically linked shared library
checking command to parse /usr/bin/nm -p output... ok
checking how to run the C preprocessor... gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking dlfcn.h usability... no
checking dlfcn.h presence... no
checking for dlfcn.h... no
checking for ranlib... ranlib
checking for strip... strip
checking for objdir... .libs
checking for gcc option to produce PIC... -fno-common
checking if gcc PIC flag -fno-common works... yes
checking if gcc static flag -static works... no
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.lo... yes
checking if gcc supports -fno-rtti -fno-exceptions... yes
checking whether the linker (/usr/bin/ld) supports shared libraries... yes
checking how to hardcode library paths into programs... unsupported
checking whether stripping libraries is possible... no
checking dynamic linker characteristics... darwin6.2 dyld
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
creating libtool
checking for ranlib... (cached) ranlib
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln -s works... yes
configure: creating ./config.status
config.status: creating Makefile
config.status: creating c/Makefile
config.status: executing depfiles commands
[honeycrisp:~/src/httpd-apreq] em% make
Making all in c
source='apache_cookie.c' object='apache_cookie.lo' libtool=yes \
depfile='.deps/apache_cookie.Plo' tmpdepfile='.deps/apache_cookie.TPlo' \
depmode=gcc /bin/sh ../depcomp \
/bin/sh ../libtool --mode=compile gcc -DPACKAGE_NAME=\\
-DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\ -DPACKAGE_STRING=\\
-DPACKAGE_BUGREPORT=\\ -DPACKAGE=\libapreq\ -DVERSION=\1.1\
-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1
-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -I. -I.
-I/usr/local/apache/include-g -O2 -c -o apache_cookie.lo `test -f
'apache_cookie.c' || echo './'`apache_cookie.c
mkdir .libs
gcc -DPACKAGE_NAME=\\ -DPACKAGE_TARNAME=\\ -DPACKAGE_VERSION=\\
-DPACKAGE_STRING=\\ -DPACKAGE_BUGREPORT=\\ -DPACKAGE=\libapreq\
-DVERSION=\1.1\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1
-DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1
-I. -I. -I/usr/local/apache/include -g -O2 -c apache_cookie.c
-Wp,-MD,.deps/apache_cookie.TPlo -fno-common -DPIC -o
.libs/apache_cookie.lo
apache_request.h:5: header file 'httpd.h' not found
apache_request.h:6: header file 'http_config.h' not found
apache_request.h:7: header file 'http_core.h' not found
apache_request.h:8: header file 'http_log.h' not found
apache_request.h:9: header file 'http_main.h' not found
apache_request.h:10: header file 'http_protocol.h' not found
apache_request.h:11: header file 'util_script.h' not found
apache_request.h:38: undefined type, found `table'
apache_request.h:47: undefined type, found `request_rec'
apache_request.h:55: undefined type, found `table'
apache_request.h:56: undefined type, found `FILE'
apache_request.h:89: undefined type, found `request_rec'
apache_request.h:95:
[SOLVED] Re: Redhat 7.2 glibc update causes problems with Apache::Cookie?
FYI, I finally got my problems with Apache::Cookie (part of libapreq) solved. Much thanks to Stas for advice on solving this problem. Here's what I found: 1) Installing the glibc 2.2.4-24 updates borked the RPM installed perl 5.6.1. Building 5.6.1 from source fixed this problem. 2) libapreq 1.0 installs the libapreq.* files into /usr/local/lib. I ended up adding the path to ld.conf. Not sure if this was necessary.
Redhat 7.2 glibc update causes problems with Apache::Cookie?
I recently applied the glibc updates described at http://www.redhat.com/support/errata/RHBA-2002-056.html to a system running Apache 1.2.22/modperl 1.2.26 on a Perl 5.6.1/Redhat Linux 7.2 system. All seemed well until I updated Apache::Cookie to the latest version and restarted apache. Apache failed to start and I got the following error messages: Starting httpd: [Thu Apr 18 13:42:14 2002] [error] Can't load '/usr/local/lib/perl5/site_perl/5.6.1/i686-linux/auto/Apache/Cookie/Cookie.so' for module Apache::Cookie: libapreq.so.1: cannot open shared object file: No such file or directory at /usr/local/lib/perl5/5.6.1/i686-linux/DynaLoader.pm line 2/usr/lib/perl5/site_perl/5.6.1/i386-linux06. at /usr/local/lib/perl5/site_perl/5.6.1/i686-linux/mod_perl.pm line 14 Compilation failed in require at /usr/local/apache/mason/handler.pl line 33. BEGIN failed--compilation aborted at /usr/local/apache/mason/handler.pl line 33. Compilation failed in require at (eval 5) line 1. /usr/local/apache/bin/apachectl start: httpd could not be started I can find Cookie.so at the directory: drwxr-xr-x2 root root 4096 Apr 18 08:25 . drwxr-xr-x 11 root root 4096 Dec 8 15:32 .. -r--r--r--1 root root0 Nov 19 08:57 Cookie.bs -r-xr-xr-x1 root root16669 Apr 18 08:25 Cookie.so I suspect that this is an issue with the glibc update not Apache::Cookie since I'm also having similar problems with Image::Magick and Time::HiRes (modules I haven't updated) while updated modules like Storable still work. Can anyone confirm this problem? Thanks,
Re: Redhat 7.2 glibc update causes problems with Apache::Cookie?
I did that Stas. I forgot to mention that I updated Apache::Cookie via CPAN. On Fri, 19 Apr 2002, Stas Bekman wrote: [snip] looks like you have a broken or missing binary package. It says exactly what's your problem - it cannot find the library. Check that you have the right symlinks from libapreq.so.1.0.0 to libapreq.so.1, or whatever it is. Have you tried building from the sources? perl -MCPAN -eshell cpan install Apache::Cookie __ 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: Doing Authorization using mod_perl from a programmers perspective
See. http://slashdot.org/articles/01/03/20/1423223.shtml On Fri, Nov 16, 2001 at 12:13:48PM -0500, Stephen Adkins wrote: FYI. This is true as a rule, that HTTP_USER_AGENT only identifies the browser type, without a serial number. Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC) Mozilla/4.0 (compatible; MSIE 5.0; MSNIA; AOL 4.0; Windows 98; DigExt) Mozilla/4.0 (compatible; MSIE 5.0; Windows 3.1) Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Opera 5.0 [en] However, I have seen in my web log the following user agents Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::0510028001e00280014005060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::2110028001e0025c00ea0503002a Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::2110028001e0027a01290505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::211003200258024b015f0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025800c001b20505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025800c001b60505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025801f3018f0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::4110032002580294011305020008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031701860505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031a018e0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031c019c05060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031e01aa0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258032001b305060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100400030003df020405060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::81100320025802f901780505000b This indicates to me that some vendors who distribute MSIE 5.0 on their PC's include some sort of ID in the HTTP_USER_AGENT that the browser reports. (!?!) (privacy advocates beware!) Stephen At 10:46 AM 11/16/2001 -0600, Joe Breeden wrote: The HTTP_USER_AGENT doesn't identify unique users. It only identifies the browser type/version (assuming it hasn't been messed with). --Joe Breeden --- If it compiles - Ship It! Aranea Texo -Original Message- From: Jon Robison [mailto:[EMAIL PROTECTED]] Sent: Friday, November 16, 2001 10:40 AM To: [EMAIL PROTECTED] Cc: Jonathan E. Paton; [EMAIL PROTECTED] Subject: Re: Doing Authorization using mod_perl from a programmers perspective fliptop wrote: Jon Robison wrote: The most relevant section for you is the Ticket system he describes. (I believe the section header says something about Cookies, but you'll know you have the right one when you see TicketAccess.pm, TicketTools.pm, and TicketMaster.pm. One nice addition is the ability to add encryption to the Ticket, and the fact that the author used an MD5 hash (of an MD5 hash!) in the cookie, so verification of the authenticity of the user is pretty solid so long as you leave in things like ip address, etc. which he uses in the cookie by default. (Although AOL and some proxy systems might cause this to be trouble). AND, he also uses a mysql db for the i have found that using the HTTP_USER_AGENT environment variable instead of ip address solves the problem with proxy servers and the md5 hash. anyone ever tried this as a simple workaround? I think one problem with that is that is fails to uniquely identify the person. Someone please tell me if I am wrong - does the USER_AGENT field get some kind of special serial number from the browser, or is it just a version identified? Best example - large company with 1000 PC's, all with same Netscape installed. How then does the HTTP_USER_AGENT field deliniate between PC's? --Jon
Re: Doing Authorization using mod_perl from a programmers perspective
See. http://slashdot.org/articles/01/03/20/1423223.shtml On Fri, Nov 16, 2001 at 12:13:48PM -0500, Stephen Adkins wrote: FYI. This is true as a rule, that HTTP_USER_AGENT only identifies the browser type, without a serial number. Mozilla/4.0 (compatible; MSIE 5.0; Mac_PowerPC) Mozilla/4.0 (compatible; MSIE 5.0; MSNIA; AOL 4.0; Windows 98; DigExt) Mozilla/4.0 (compatible; MSIE 5.0; Windows 3.1) Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Mozilla/4.0 (compatible; MSIE 5.0; Windows 95) Opera 5.0 [en] However, I have seen in my web log the following user agents Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::0510028001e00280014005060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::2110028001e0025c00ea0503002a Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::2110028001e0027a01290505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::211003200258024b015f0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025800c001b20505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025800c001b60505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100320025801f3018f0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::4110032002580294011305020008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031701860505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031a018e0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031c019c05060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258031e01aa0505000b Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::411003200258032001b305060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::41100400030003df020405060008 Mozilla/4.0 (compatible; MSIE 5.0; Windows 95)::ELNSB50::81100320025802f901780505000b This indicates to me that some vendors who distribute MSIE 5.0 on their PC's include some sort of ID in the HTTP_USER_AGENT that the browser reports. (!?!) (privacy advocates beware!) Stephen At 10:46 AM 11/16/2001 -0600, Joe Breeden wrote: The HTTP_USER_AGENT doesn't identify unique users. It only identifies the browser type/version (assuming it hasn't been messed with). --Joe Breeden --- If it compiles - Ship It! Aranea Texo -Original Message- From: Jon Robison [mailto:[EMAIL PROTECTED]] Sent: Friday, November 16, 2001 10:40 AM To: [EMAIL PROTECTED] Cc: Jonathan E. Paton; [EMAIL PROTECTED] Subject: Re: Doing Authorization using mod_perl from a programmers perspective fliptop wrote: Jon Robison wrote: The most relevant section for you is the Ticket system he describes. (I believe the section header says something about Cookies, but you'll know you have the right one when you see TicketAccess.pm, TicketTools.pm, and TicketMaster.pm. One nice addition is the ability to add encryption to the Ticket, and the fact that the author used an MD5 hash (of an MD5 hash!) in the cookie, so verification of the authenticity of the user is pretty solid so long as you leave in things like ip address, etc. which he uses in the cookie by default. (Although AOL and some proxy systems might cause this to be trouble). AND, he also uses a mysql db for the i have found that using the HTTP_USER_AGENT environment variable instead of ip address solves the problem with proxy servers and the md5 hash. anyone ever tried this as a simple workaround? I think one problem with that is that is fails to uniquely identify the person. Someone please tell me if I am wrong - does the USER_AGENT field get some kind of special serial number from the browser, or is it just a version identified? Best example - large company with 1000 PC's, all with same Netscape installed. How then does the HTTP_USER_AGENT field deliniate between PC's? --Jon
Re: best way to handle my-website-configuration.xml?
On Tue, Sep 25, 2001 at 02:59:07PM +0200, Robin Berjon wrote: With AxKit you can seamlessly serve XML transformed by a variety of things, including XSLT. It is fast (esp 1.5 beta) and it has its own internal caching engine that makes it even faster. Also, it can cooperate with a number of dynamic generation packages. Is 1.4_82 this 1.5 beta you speak of? If not, where can 1.5 be found? Is cvs alive again? Thanks, Edward
RE: Need Some Help
I tried bot the options separately and I tried them together neither seem to work. I have looked though every thing I could fine but what docs are you referring to ? -Original Message- From: Stas Bekman [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 11, 2001 7:09 PM To: Perry Edward (tsp2emp) Cc: '[EMAIL PROTECTED]' Subject: Re: Need Some Help On Thu, 11 Jan 2001, Perry Edward (tsp2emp) wrote: I have just downloaded 2 Modules from cpan.org. They appear to be compiling and installing fine but I am having problems. I was hoping someone could give me some direction to look in DBI mod_perl When I start Apache I receive an error "Rebuild with -DPERL_STACKED_HANDLERS to $r-push_handlers at /usr/local/lib/perl5/site_perl/5.005/Apache/DBI.pm line 30." Apache is installed in /opt/Apache version 1.3 I have enabled "PERL_CHILD_INIT" and "PERL_STACKED_HANDLERS" when compiling mod_perl and it showed as enabled but when compiling everything (Apache/Mod_Perl) the compilers commands show "-DNO_PERL_STACKED_HANDLERS" and "-DNO_PERL_CHILD_INIT". So I did a make clean did the configuration over again but before I did a make I went though ever Makefile and changed "-DNO_PERL" to "-DPERL_" but made no change in the out come of my problem. Have you read the docs? Try: % perl Makefile.PL PERL_STACKED_HANDLERS=1 or % perl Makefile.PL EVERYTHING=1 Any suggestions or direction would be most appreciated. Edward Perry _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://logilune.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Need Some Help
I have just downloaded2 Modules from cpan.org. They appear to be compiling and installing fine but I am having problems. I was hoping someone could give me some direction to look in DBI mod_perl When I start Apache I receive an error "Rebuild with -DPERL_STACKED_HANDLERS to $r-push_handlers at /usr/local/lib/perl5/site_perl/5.005/Apache/DBI.pm line 30." Apache is installed in /opt/Apache version 1.3 I have enabled "PERL_CHILD_INIT" and "PERL_STACKED_HANDLERS" when compiling mod_perl and it showed as enabled but when compiling everything (Apache/Mod_Perl) the compilers commands show "-DNO_PERL_STACKED_HANDLERS" and "-DNO_PERL_CHILD_INIT". So I did a make clean did the configuration over again but before I did a make I went though ever Makefile and changed "-DNO_PERL" to "-DPERL_" but made no change in the out come of my problem. Any suggestions or direction would be most appreciated. Edward Perry
[Solved]: Apache::Compress + mod_proxy problem
Here's a patch for Apache::Compress that passes off proxied requests to
mod_proxy.
Without this patch Apache::Compress will return an internal server error
since it can't find the proxied URI on the local filesystem.
Much of the patch was lifted from chapter 7 of the Eagle book.
Right now the code requires you to write proxy settings twice (i.e. in the
FileMatch block for Apache::Compress and in the mod_proxy section):
FilesMatch "\.(htm|html)$"
SetHandler perl-script
PerlSetVar PerlPassThru '/proxy/ =
http://private.company.com/,
/other/ = http://www.someother.co.uk'
PerlHandler Apache::Compress
/FilesMatch
ProxyRequests On
ProxyPass /proxy http://private.company.com/
ProxyPassReverse/proxy http://private.company.com/
ProxyPass /other http://www.someother.co.uk/
ProxyPassReverse/other http://www.someother.co.uk/
34a35,49
if ($r-proxyreq) {
use Apache::Proxy;
my $uri = $r-uri();
my %mappings = split /\s*(?:,|=)\s*/, $r-dir_config('PerlPassThru');
for my $src (keys %mappings) {
next unless $uri =~ s/^$src/$mappings{$src}/;
}
my $status = Apache::Proxy-pass($r, $uri);
return $status;
}
Re: Dynamic content that is static
Not necessarily. You can use mod_proxy to cache the dynamically generated pages on the lightweight apache. Check out http://perl.apache.org/guide/strategy.html#Apache_s_mod_proxy for details on what headers you'll need to set for caching to work. On Fri, 22 Dec 2000, Philip Mak wrote: Hi everyone, I have been going over the modperl tuning guide and the suggestions that people on this list sent me earlier. I've reduced MaxClients to 33 (each httpd process takes up 3-4% of my memory, so that's how much I can fit without swapping) so if the web server overloads again, at least it won't take the machine down with it. Running a non-modperl apache that proxies to a modperl apache doesn't seem like it would help much because the vast majority of pages served require modperl.
Re: Dynamic content that is static
You should check out the documentation on mod_proxy to see what it's capable of: http://httpd.apache.org/docs/mod/mod_proxy.html You can specify expiration values and be assured that cached files older than expiry will be deleted. So, for example, if you know that your content gets updated every 48 hours you can specify 'CacheMaxExpire 48' and force the proxy server to retrieve a new copy every 48 hours. You can also set headers within a dynamic document that specifies an expiration time. Check out the link in my previous e-mail for more info. On Fri, 22 Dec 2000, Philip Mak wrote: I thought about this... but I'm not sure how I would tell the lightweight Apache to refresh its cache when a file gets changed. I suppose I could graceful restart it, but the other webmasters of the site do not have root access. (Or is there another way? Is it possible to teach Apache or Squid that ccs.htm depends on header.asp, footer.asp, series.dat and index.inc?) Also, does this mess up the REMOTE_HOST variable, or is Apache smart enough to replace that with X-Forwarded-For when the forwarded traffic is being sent from a local priviledged process? -Philip Mak ([EMAIL PROTECTED])
Apache::Compress + mod_proxy problem
I've run into a problem with Apache::Compress in dealing with mod_proxyed content. The author of Apace::Compress suggested that I post the problem here. I'm running apache 1.3.14, mod_perl 1.24_01, Apache::Compress 1.003 on a RedHat 6.2 linux box. I get an internal server error when ever I try to request a file ending with .htm/.html on a proxied server. Meaning: www.company.com/local/index.html - OK, contents are compressed www.company.com/proxy/ - OK, contents are NOT compressed www.company.com/proxy/index.html - 500 error w/ Apache::Compress www.company.com/proxy/script.pl - OK, contents are NOT compressed Apache::Compress tries to map the URI to the filesystem and ends up with an undefined filehandle for content residing on the remote server and returns SERVER_ERROR. I've modified Apache::Compress to special case proxy requests, but I can't figure out how to do a redirect to mod_proxy from within Apache::Compress. Is this the best way to resolve this issue? I've been reading the eagle book and I'm guessing I could use a Translation Handler to handle this as well. Here are the relevant sections of httpd.conf: PerlModule Apache::Compress FilesMatch "\.(htm|html)$" SetHandler perl-script PerlHandler Apache::Compress /FilesMatch IfModule mod_proxy.c ProxyRequests On ProxyVia Off ProxyPass /proxy http://internalserver/ ProxyPassReverse/proxy http://internalserver/ /IfModule
[OT] mod_proxy tuning info?
I'm looking for docs or white papers on tuning apache/mod_proxy for optimum performance when acting as a reverse proxy for a web farm. Can anyone point me to a URL or a book that's a good reference? Thanks,
Re: [OT] mod_proxy tuning info?
Yes, I have read that part of the mod_perl guide. I'm looking for a more detailed discussion on mod_proxy configuration and performance. But it doesn't answer the questions I have regarding the use of mod_proxy: * What affect does CacheGcInterval have on performance? * Does setting CacheDirLevels to a high value cause a performance hit? * Does setting CacheDirLength to a small value increase performance? * How does performance scale with 1GB, 2GB, or 4GB of memory? * How do you determine the overall hit rate? The hit rate from ram? The hit rate from disk? * There are dynamic pages I want cached for a certain TTL. There are other dynamic pages I don't want cached at all. Do I have to use the NoCache directive on all the directories/files I don't want cached? Or is there a more effective way to do this? On Tue, 15 Aug 2000, ___cliff rayman___ wrote: have u read this yet? http://perl.apache.org/guide/scenario.html#mod_proxy Edward Moon wrote: I'm looking for docs or white papers on tuning apache/mod_proxy for optimum performance when acting as a reverse proxy for a web farm. Can anyone point me to a URL or a book that's a good reference? Thanks, -- ___cliff [EMAIL PROTECTED]http://www.genwax.com/
Re: Trying to setup embedded Perl
It seems as if this site is already running Apache/mod_perl (according to
Netcraft) so as long as you can get hold of the particular module
responsible for this then you should have no problems.
--
Edward Thomas | [EMAIL PROTECTED]
Cynosure Design | www.cyno.co.uk
- Original Message -
From: "Dennis" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Saturday, April 22, 2000 5:13 PM
Subject: Trying to setup embedded Perl
Hey
can you throw some helpful hints on the problem I'm having ?
I'm trying to move a working site from singleslibrary.com to my server.
Unfortunately the guy who wrote the site for us is not available anymore ..
and nobody seems to know what to do, including me.
What I'm trying to do is setup the following:
I have HTML code, the one like in P.S.
and it seems to have Perl embedded in between : and !----
brackets
can Apache handle that ? do I need some other program ? Just wondering if
I can use apache to do that
P.S.
I took the following HTML/Perl parts from
http://singleslibrary.com/dynahtml/singles/sample.html
tr VALIGN=bottomtd align=rightDo you have children?/tdtdfont
COLOR=#002070b:field('chihome')/b/font/td/tr
EOF
:htmlselect( 'chil', CHIHOME, NULL )
tr VALIGN=bottomtd align=rightDo you drink?/tdtdfont
COLOR=#002070b:field('drink')/b/font/td/tr
tr VALIGN=bottomtd align=right Do you smoke?/tdtdfont
COLOR=#002070b:field('smoke')/b/font/td/tr
!--: skip( time %3 ) --
A href_ifpw("home.html","active.html") TARGET=_topIMG Align=Top
SRC="/htdocs/singles/images/profiles1.jpg" BORDER=0/A!--: skip(2) --
A href_ifpw("home.html","active.html") TARGET=_topIMG Align=Top
SRC="/htdocs/singles/images/profiles2.jpg" BORDER=0/A!--: skip(1) --
A href_ifpw("home.html","active.html") TARGET=_topIMG Align=Top
SRC="/htdocs/singles/images/profiles3.jpg" BORDER=0/A
P
Re: mod_perl (preferably Embperl) based shopping cart?
Check out http://www.opensales.org/. I don't recall if they use mod_perl or Embperl, but I do know that they use Perl (gee is that vague enough :). On Thu, 10 Feb 2000, Jason Bodnar wrote: A while ago somebody posted that they were working on an open source shopping cart using mod_perl. Did anything come of that? I'm wroking with minivend right now and, well, it's not very nice. What would be nice is to have a perl Minivend API (since it's so full-featured) so you could create your pages with Embperl, ePerl, Apache::ASP, etc and still use the MiniVend backend. --- Jason Bodnar + [EMAIL PROTECTED] + Tivoli Systems In Jail Rock house Rock, he was everything Rockabilly's about. No, I mean he is Rockabilly. Mean, Surly, Nasty, Brute. I mean in that movie he couldn't give a about nothin'. Just rockin' and rollin', livin' fast, dying young, leavin' a good lookin' corpse. --Clarence Worley, True Romance
