Re: mod_perl and CGI.pm and version 1.x and hell
Henrique Pantarotto wrote: I'm having some trouble with CGI.pm working with mod_perl2. What trouble are you having? This guy clearly says that CGI.pm is incompatible with mod_perl2: http://marc.theaimsgroup.com/?l=apache-modperlm=103619647305553w=2 That was 7 months ago. A lot has changed. Keep in mind, CGI.pm doesn't entirely work with mod_perl 1. It uses global variables internally, so it has to clear them with a cleanup handler, and there are issues around subrequests. This isn't really a big problem, but I have 3 ways out: 1) help make CGI.pm compatible with mod_perl2 if at all possible 2) replace all CGI.pm calls with simple homemade cgi functions (not difficult, it's just that we have to correct many scripts that already count on CGI.pm), or use that Apache::compat thing You could try CGI::Simple, which has the same (OO) interface as CGI.pm. 3) downgrade apache to 1.3.27 and mod_perl to 1.27 and be happy That would work fine as well. Seriously, does mod_perl2 offer much more features and benefits then mod_perl1? I really only care for speed and stability for simple perl scripts that use CGI/DBI/DBD::mysql modules. It offers many new features, which are described here: http://perl.apache.org/docs/2.0/user/intro/overview.html#What_s_new_in_mod_perl_2_0 The most common reasons for switching at this point are to get filtering or to get multi-threading on Win32. Is it okay if I use mod_perl and apache 1.x today, or it's better to move to 2.x already? Many people are stil developing on 1.x, including me, and there is a new release of it due out any day. Go ahead, if that makes you more comfortable. - Perrin
Re: [mp2] make test fails on redhat 8.0 with 1.99_09 and 1.99_10-devsources
On Today at 12:03pm, SB=Stas Bekman [EMAIL PROTECTED] wrote: SB SB In the case of 1.99_09, following happens after running make test SB SB [Mon Jun 02 15:55:16 2003] [error] Invalid CODE attribute: SB TestFilter::out_init_basic at SB /home/haroon/src/build/mod_perl-1.99_09/t/filter/TestFilter/out_init_basic.pm SB line 33 BEGIN failed--compilation aborted at SB /home/haroon/src/build/mod_perl-1.99_09/t/filter/TestFilter/out_init_basic.pm SB line 33. Compilation failed in require at (eval 21) line 3. SB SB I hate when this happens :( I remember seeing this problem at some SB point, but I wasn't able to reproduce it since then. I have exactly SB the same perl build as in your report. The only difference is that SB I've built it with: -Doptimize='-g'. I'm not sure if it'd make any SB difference. But can you try building a custom perl using SB -Doptimize='-g' and all the options that you had: Hi Stas, Unfortunately I only have developer access on that machine. Since I don't have root access does this mean that first I might have to install perl as a regular user in my home directory and then install mod_perl built against the locally built perl? SB SB config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 SB -Dmyhostname=localhost [EMAIL PROTECTED] -Dcc=gcc SB -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr SB -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr SB -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid SB -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog SB -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005 SB -Uversiononly -Dpager=/usr/bin/less -isr' SB SB and give it another try? SB SB Anybody else sees this problem? SB We could wait and see if anyone else has the same problem. SB Another difference from perl -v is SB -libc=/lib/libc-2.2.92.so, so=so, useshrplib=true, libperl=libperl.so SB -gnulibc_version='2.2.92' SB +libc=/lib/libc-2.2.5.so, so=so, useshrplib=true, libperl=libperl.so SB +gnulibc_version='2.2.5' SB SB but I doubt this has anything to do with it. SB Cheers, -- Haroon Rafique [EMAIL PROTECTED]
Re: modperl 2.0: apache crashes when running modperl script
-8-- Start Bug Report 8--
1. Problem Description:
apache crashes when accessing this modperl script:
package Apache::hello;
use strict;
use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::Const -compile = 'OK';
sub handler {
my $request = shift; # what does shift operate on @_?
$request-content_type('text/html');
$request-print(END);
HTML
BODY
H1Hello There/H1
/BODY
/HTML
END
return Apache::OK;
}
2. Used Components and their Configuration:
*** using /usr/download/modperl/mod_perl-1.99_09/t/../lib/Apache/BuildConfig.pm
*** Makefile.PL options:
MP_AP_PREFIX= /usr/httpd20
MP_COMPAT_1X= 1
MP_GENERATE_XS = 1
MP_INST_APACHE2 = 1
MP_LIBNAME = mod_perl
MP_USE_DSO = 1
MP_USE_STATIC = 1
*** /usr/httpd20/bin/httpd -V
Server version: Apache/2.0.46
Server built: Jun 1 2003 19:52:02
Server's Module Magic Number: 20020903:3
Architecture: 32-bit
Server compiled with
-D APACHE_MPM_DIR=server/mpm/prefork
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D HTTPD_ROOT=/usr/httpd20
-D SUEXEC_BIN=/usr/httpd20/bin/suexec
-D DEFAULT_PIDLOG=logs/httpd.pid
-D DEFAULT_SCOREBOARD=logs/apache_runtime_status
-D DEFAULT_LOCKFILE=logs/accept.lock
-D DEFAULT_ERRORLOG=logs/error_log
-D AP_TYPES_CONFIG_FILE=conf/mime.types
-D SERVER_CONFIG_FILE=conf/httpd.conf
*** /usr/bin/perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
Platform:
osname=linux, osvers=2.4.18-11smp, archname=i386-linux-thread-multi
uname='linux daffy.perf.redhat.com 2.4.18-11smp #1 smp thu aug 15 06:41:59 edt
2002 i686 i686 i386 gnulinux '
config_args='-des -Doptimize=-O2 -march=i386 -mcpu=i686 -Dmyhostname=localhost
[EMAIL PROTECTED] -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr
-Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Duseshrplib -Dusethreads
-Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm
-Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005
-Uversiononly -Dpager=/usr/bin/less -isr'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
optimize='-O2 -march=i386 -mcpu=i686',
cppflags='-D_REENTRANT -D_GNU_SOURCE -fno-strict-aliasing -I/usr/include/gdbm'
ccversion='', gccversion='3.2 20020822 (Red Hat Linux Rawhide 3.2-5)',
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=8
alignbytes=4, prototype=define
Linker and Libraries:
ld='gcc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil
perllibs=-lnsl -ldl -lm -lpthread -lc -lcrypt -lutil
libc=/lib/libc-2.2.92.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.2.92'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic
-Wl,-rpath,/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'
Characteristics of this binary (from libperl):
Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT
Built under linux
Compiled at Sep 1 2002 23:56:49
%ENV:
PERL_LWP_USE_HTTP_10=1
@INC:
/usr/lib/perl5/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/5.8.0
/usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.0
/usr/lib/perl5/vendor_perl
.
3. This is the core dump trace: (if you get a core dump):
I was able to run 'httpd -X' from inside gbd and got a stack trace
with mod_perl compiled with MP_DEBUG=1:
0x402f458c in modperl_wbucket_write (my_perl=0x81af228, wb=0x81b3900,
buf=0xb438 4, wlen=0x4063cb8f) at modperl_filter.c:181
181 *wlen = 0;
#0 0x402f458c in modperl_wbucket_write (my_perl=0x81af228, wb=0x81b3900,
buf=0xb438 4, wlen=0x4063cb8f) at modperl_filter.c:181
#1 0x40640701 in mpxs_Apache__RequestRec_print ()
from
Fw: Missing html code using dynagzip
Sorry, I've just hit a wrong button... - Original Message - From: Slava Bizyayev [EMAIL PROTECTED] To: Scott Alexander [EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 9:41 AM Subject: Re: Missing html code using dynagzip - Original Message - From: Scott Alexander [EMAIL PROTECTED] To: Slava Bizyayev [EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 4:06 AM Subject: Re: Missing html code using dynagzip Well only by experiment I noticed the problem went away. The Compress::LeadingBlankSpaces reduced the bytes sent by still abit. I'm glad to know that... Could the problem be caused by some other setting I have in httpd.conf file? Difficult to say blindly... Thanks, Slava
RE: Apache::Cookie
it works just fine in my app, and 'just fine' maybe all that i need. do you
have a better solution, or are you just pointing out the error?
-Original Message-
From: Stas Bekman [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2003 10:08 PM
To: [EMAIL PROTECTED]
Cc: Perrin Harkins; modperl
Subject: Re: Apache::Cookie
cap wrote:
Well, here's what I have to do to get direct access to values from the
original cookie hash:
my $cookies = Apache::Cookie-fetch;
my %hash = defined $cookies-{'session'} ? $cookies-{'session'}-value :
undef;
Strange. Thanks for the lead.
That's a bogus code. Obviously you are running without warnings
mode on. Add:
use warnings;
and you will see why it is bogus. Perhaps your cookie was always
valid so you
didn't notice it. Howerer:
perl -lwe '%h = undef'
Name main::h used only once: possible typo at -e line 1.
Odd number of elements in hash assignment at -e line 1.
Use of uninitialized value in list assignment at -e line 1.
-Original Message-
From: Perrin Harkins [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2003 2:41 PM
To: [EMAIL PROTECTED]
Cc: modperl
Subject: Re: Apache::Cookie
On Mon, 2003-06-02 at 09:05, cap wrote:
i have an application that uses CGI and sets the cookie values
as a hashref.
im then attempting to retreive the values with Apache::Cookie with:
$cookies = Apache::Cookie-fetch;
$ccokies is a hashref so i should be able to get the individual
values with:
$cookies-{uid};
right? however, this doesn't appear to work.
I see the problem. There is mistake in the Apache::Cookie
documentation, but the correct way to do this is shown in the mod_perl
guide:
http://perl.apache.org/docs/1.0/guide/porting.html#Converting_to_us
e_Apache_Perl_Modules
Change your last line to this:
my $uid = defined $cookies-{'uid'} ? $cookies-{'uid'}-value() :
undef;
- Perrin
--
__
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: Apache::Cookie
On Tue, 2003-06-03 at 13:08, cap wrote:
it works just fine in my app, and 'just fine' maybe all that i need.
The point is, it shouldn't work. You should not be getting a hash.
What should work is this:
my $session = defined $cookies-{'session'} ?
$cookies-{'session'}-value : undef;
The larger issue is fixing the Apache::Cookie docs. I would attempt to
patch it if I understood what it's doing. Does anyone know what the API
is returning when you call fetch()? An Apache::Table? Some other kind
of object? It looks pretty bizarre to me, and it certainly isn't doing
what the docs show.
- Perrin
[ANNOUNCE] Practical mod_perl is out!
well, the (long) wait is now over - Practical mod_perl is here. weighing in at a whopping 924 pages, Practical mod_perl really needs no introduction for those that are already familiar with the mod_perl Guide. however, from the ORA catalog description: From writing and debugging scripts to keeping your server running without failures, the techniques in this book will help you squeeze every ounce of power out of your server. True to its title, this is the practical guide to mod_perl. O'Reilly has a sample chapter online http://www.oreilly.com/catalog/pmodperl/chapter/ch06.pdf the book's official website is http://www.modperlbook.org/ where you will find links to ways to purchse the book. kudos Stas and Eric! --Geoff
Re: [ANNOUNCE] Practical mod_perl is out!
Geoffrey Young wrote: well, the (long) wait is now over - Practical mod_perl is here. weighing in at a whopping 924 pages, Practical mod_perl really needs no introduction for those that are already familiar with the mod_perl Guide. however, from the ORA catalog description: From writing and debugging scripts to keeping your server running without failures, the techniques in this book will help you squeeze every ounce of power out of your server. True to its title, this is the practical guide to mod_perl. O'Reilly has a sample chapter online http://www.oreilly.com/catalog/pmodperl/chapter/ch06.pdf the book's official website is http://www.modperlbook.org/ where you will find links to ways to purchse the book. kudos Stas and Eric! --Geoff I have a mod_perl book but I am looking forward to one that includes mod_perl. I believe, corporate IT should take a serious look at using mod_perl. It is time for the heads to come out of the sand. I am interested in creating a presentation for my employer. I need information that reeks (yes I want it to stink) with credibility. Any pointers in this regard is welcome.
RE: [ANNOUNCE] Practical mod_perl is out!
well, the (long) wait is now over - Practical mod_perl is here. Geoff, you might be the best person to ask and it might be a worthwhile extension to the mod_perl-documentation: why would one use this new book if (s)he has the mod_perl cookbook already. I am not trying to set a new war between authors here, but wouldn't it be an idea to have such a 'review', giving interested users an idea of what they could buy? On one of my shopping sprees I bought 'Perl in a nutshell' and not that much later the Camel-book, only to find that I can put the nutshell far away as I never read it (sorry author). This experience is holding me back a bit when it is about buying a new book that covers the same subject as another book. Hope you can help us! --Frank
RE: Apache::Cookie
Okay, I'm obviously no expert but I see a problem ... I think? :
my $cookie = Apache::Cookie-fetch;
my $ref_cookie = ref $cookie;
returns 'HASH'
but
my $session = $cookies-{'session'}-value;
my $type = ref @session;
doesn't return anything, '' or (undef?). strange?
However:
my @session = $cookies-{'session'}-value;
returns the (almost) desired result as pairs and as they were originally
inserted from the standard CGI cookie. so i thought it was acceptable to
convert to a hash, knowing the list values are in pairs:
my %hash = $cookies-{'session'}-value;
will probably throw a warning or even an error without the defined
statement, but it gets past the immediate issue.
kirk
-Original Message-
From: Perrin Harkins [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2003 10:57 AM
To: [EMAIL PROTECTED]
Cc: Stas Bekman; modperl
Subject: RE: Apache::Cookie
On Tue, 2003-06-03 at 13:08, cap wrote:
it works just fine in my app, and 'just fine' maybe all that i need.
The point is, it shouldn't work. You should not be getting a hash.
What should work is this:
my $session = defined $cookies-{'session'} ?
$cookies-{'session'}-value : undef;
The larger issue is fixing the Apache::Cookie docs. I would attempt to
patch it if I understood what it's doing. Does anyone know what the API
is returning when you call fetch()? An Apache::Table? Some other kind
of object? It looks pretty bizarre to me, and it certainly isn't doing
what the docs show.
- Perrin
Re: [ANNOUNCE] Practical mod_perl is out!
Frank Maas wrote: well, the (long) wait is now over - Practical mod_perl is here. Geoff, you might be the best person to ask and it might be a worthwhile extension to the mod_perl-documentation: why would one use this new book if (s)he has the mod_perl cookbook already. that's a valid question. the way I look at things is like this. mod_perl is in a very unique position. of the three substantial books available on mod_perl, all are useful and authoritative, and all overlap very, very little. for the most part, I would say that the eagle book is best viewed as the main API reference for mod_perl - (almost) all the API functions are explained and illustrated there. it's also a good introductory text on basic Apache functionality and how mod_perl ties into Apache. I think everyone would agree that to do mod_perl you need to own the eagle book. the cookbook tries to show what having the C Apache API at your fingertips really means to Perl programmers. for the most part, it gives lots of examples of using (and abusing) the mod_perl API as a means to extending (and contorting) Apache. there is very little there, for instance, on running and configuring a server, but lots there on programming the deepest recesses of the server. practical mod_perl I think is more of an overall guide to deploying mod_perl services - everything from basic setup and coding to advanced configurations and performance techniques. essentially an overhauled, reworked, and polished Guide, this book has been in the works for a long time, and it contains very valuable information you won't find anywhere else. as I said, you'll find very little overlap between the different books. I know I tried very hard not to duplicate information that you could simply find in the eagle book, and I had advance knowledge of what was in the new book, so I tried not to duplicate information available there either. Stas and Eric I'm sure did the same. I am not trying to set a new war between authors here actually, we're all very much on friendly terms, so a war isn't likely. despite writing through different publishers, we all have the same idea - namely, to promote mod_perl and help document it as best we can. I know that's not something you find in open source every day, but you'll find us all drinking together at OSCon again this year :) --Geoff
Re: mod_perl and CGI.pm and version 1.x and hell
Option 3 seems okay, excect for the fact that I am that kind of Linux user that is always upgrading everything to the latest version possible. This applies to linux kernel, apache, etc. I don't really have a reason to do this, but I have always done it anyway. You're nuts. I'd fire you. :) In other words, are you saying that you'll hire me? I plan on moving to England within the next 2 or 3 years. I'll send you an e-mail then and ask for a job. Probrably by then there'll be mod_perl3 and apache 4! Anyway, I promise I won't rush on upgrading things frenetically. ;-) Just out of interest, which kernel are you using? This is a production server, so I am using stable 2.4.20. Wouldn't be responsible of me running 2.5.x in there right? Well *real* Linux users only code in C and assembler - that'll give you the speed... You're right! But for simple and/or fast development scripts, I think perl with mod_perl make an excellent pair. But if you want ultra-light and really fast cgi programs, I agree that it really needs to be done in C. By and large, 1.x is what the business world is using, and 2.x is not-quite-bleeding-edge. Before Stas jumps on me again, there's not a lot wrong with it, but I won't be using it for anything that involves money until things have settled down quite a lot. I didn't know this. Have you asked your employer what he thinks about it? He would say WHAT (in portuguese though) Regards from Brazil, Henrique.
Re: [ANNOUNCE] Practical mod_perl is out!
On Tue, 2003-06-03 at 16:10, Geoffrey Young wrote: I know that's not something you find in open source every day, but you'll find us all drinking together at OSCon again this year :) Stas will be drinking cranberry juice, but still drinking. Congratulations on the publication, Eric and Stas! - Perrin
Re: mod_perl and CGI.pm and version 1.x and hell
Henrique Pantarotto wrote: I'm having some trouble with CGI.pm working with mod_perl2. What trouble are you having? logs/error_log reported this: [Fri May 30 09:21:20 2003] [error] [client 10.29.31.104] Can't locate Apache.pm in @INC (@INC contains: /home /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache2 /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl . /usr/local/apache/ /usr/local/apache/lib/perl) at /usr/lib/perl5/5.8.0/CGI.pm line 162. I noticed CGI.pm does a require Apache, and I don't seem to have this Apache.pm file. This guy clearly says that CGI.pm is incompatible with mod_perl2: http://marc.theaimsgroup.com/?l=apache-modperlm=103619647305553w=2 That was 7 months ago. A lot has changed. I confess I didn't try to hack this in to much detail. I searched the mailing-list and I found many threads saying bad things about CGI.pm and mod_perl2, so I thought about asking this list this very specific question. You could try CGI::Simple, which has the same (OO) interface as CGI.pm. That's a really cool hint. Thanks!! I've neved used CGI::Simple before, and I'll take a look at it. Although cpan.org/modules/by-module/CGI/Cgi-Simple-0.06.readme warns about not using this module with production environment.. but they all say that right? Hmm.. little red devil in left shoulder yells YES!, GO FOR IT, little blue angel in another shoulder says no henrique, think. Seriously, does mod_perl2 offer much more features and benefits then mod_perl1? I really only care for speed and stability for simple perl scripts that use CGI/DBI/DBD::mysql modules. It offers many new features, which are described here: http://perl.apache.org/docs/2.0/user/intro/overview.html#What_s_new_in_mod_perl_2_0 The most common reasons for switching at this point are to get filtering or to get multi-threading on Win32. Don't need Win32. ;-) Is it okay if I use mod_perl and apache 1.x today, or it's better to move to 2.x already? Many people are stil developing on 1.x, including me, and there is a new release of it due out any day. Go ahead, if that makes you more comfortable. I think I'll do that. Thanks a lot for sharing your experience with me. Thanks, Henrique.
Re: modperl 2.0: apache crashes when running modperl script
[EMAIL PROTECTED] wrote: [...] 3. This is the core dump trace: (if you get a core dump): I was able to run 'httpd -X' from inside gbd and got a stack trace with mod_perl compiled with MP_DEBUG=1: 0x402f458c in modperl_wbucket_write (my_perl=0x81af228, wb=0x81b3900, buf=0xb438 4, wlen=0x4063cb8f) at modperl_filter.c:181 181 *wlen = 0; #0 0x402f458c in modperl_wbucket_write (my_perl=0x81af228, wb=0x81b3900, buf=0xb438 4, wlen=0x4063cb8f) at modperl_filter.c:181 #1 0x40640701 in mpxs_Apache__RequestRec_print () from /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/auto/Apache/RequestIO/RequestIO.so #2 0x4063e8c6 in XS_Apache__RequestRec_print () from /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/auto/Apache/RequestIO/RequestIO.so why RequestIO.so doesn't include the debug info? Are you sure you have run 'make install' after you have rebuilt mod_perl with MP_DEBUG=1? try to nuke /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi/auto/Apache and 'make install' again. Actually I know why this happens and why you have the segfault since you have had: MP_INST_APACHE2 = 1 it must be installed into i686-linux-thread-multi/Apache2/auto/Apache/RequestIO/RequestIO.so You probably had an older mod_perl install, and now it loads the wrong library. I see that you didn't load Apache2 and that explains the problem. Add to your startup 'use Apache2' as explained here: http://perl.apache.org/docs/2.0/user/intro/start_fast.html#Configuration __ 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: Problem with a custom response handler and mod_perl 2
Alejandro Galue wrote: Hello, I'm using redhat 8.0 (mod_perl-1.99_05-3, httpd-2.0.40-11.3). I created a custom handler for http responses, and I get this error in httpd log: [Tue Jun 03 07:42:53 2003] [error] [client 127.0.0.1] Can't locate object method header_in via package Apache::RequestRec at /usr/lib/perl5/site_perl/sgi/apache/cgi/init.pm line 27.!, referer: http://localhost:8080/main.html BUT, I have other redhat 8.0 implementation with the same handler and does not have this problem. Any suggestions RTFM, http://perl.apache.org/docs/2.0/user/porting/compat.html#C__r_E_gt_header_in_ __ 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: mod_perl and CGI.pm and version 1.x and hell
Henrique Pantarotto wrote: Henrique Pantarotto wrote: I'm having some trouble with CGI.pm working with mod_perl2. What trouble are you having? logs/error_log reported this: [Fri May 30 09:21:20 2003] [error] [client 10.29.31.104] Can't locate Apache.pm in @INC (@INC contains: /home /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi/Apache2 /usr/lib/perl5/5.8.0/i386-linux-thread-multi /usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl . /usr/local/apache/ /usr/local/apache/lib/perl) at /usr/lib/perl5/5.8.0/CGI.pm line 162. I noticed CGI.pm does a require Apache, and I don't seem to have this Apache.pm file. it helps when problem reports include information that helps to debug the problem. We can't possibly guess what setup you are using. In this case which CGI version are you using? CGI 2.93 works just fine with mp1 and mp2. CGI.pm does 'require Apache' only if it detects no mod_perl 2, but mod_perl 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
Re: [mp2] make test fails on redhat 8.0 with 1.99_09 and 1.99_10-devsources
Haroon Rafique wrote: On Today at 12:03pm, SB=Stas Bekman [EMAIL PROTECTED] wrote: SB SB In the case of 1.99_09, following happens after running make test SB SB [Mon Jun 02 15:55:16 2003] [error] Invalid CODE attribute: SB TestFilter::out_init_basic at SB /home/haroon/src/build/mod_perl-1.99_09/t/filter/TestFilter/out_init_basic.pm SB line 33 BEGIN failed--compilation aborted at SB /home/haroon/src/build/mod_perl-1.99_09/t/filter/TestFilter/out_init_basic.pm SB line 33. Compilation failed in require at (eval 21) line 3. SB SB I hate when this happens :( I remember seeing this problem at some SB point, but I wasn't able to reproduce it since then. I have exactly SB the same perl build as in your report. The only difference is that SB I've built it with: -Doptimize='-g'. I'm not sure if it'd make any SB difference. But can you try building a custom perl using SB -Doptimize='-g' and all the options that you had: Hi Stas, Unfortunately I only have developer access on that machine. Since I don't have root access does this mean that first I might have to install perl as a regular user in my home directory and then install mod_perl built against the locally built perl? Yes, it should be pretty easy. However I have forgotten that I have a system-wise perl-5.8.0 installed which is compliled without debugging and seems to have the same build and I don't have this problem with it. In any case please give it a try, since I know that I have changed something and the problem was gone. Is it possible that you have an old install and it gets loaded instead? Can you try nuking any preinstalled mod_perl libs? __ 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: USE_ENVIRON_ARRAY
Beau E. Cox wrote: Hi - I'm working on an embedding project, and using mod_perl as a tutorial (OK, I'm sometimes blatantly stealing code :)). My tests on a WIN32 box (Win2K) are somewhat flaky. Linux is solid. A grep of mod perl source on WIN32 led me to so pretty strange environment array spoofing based upon #ifdef USE_ENVIRON_ARRAY in modperl_perl.c. The only greps to USE_ENVIRON_ARRAY are in modperl_perl.c. NO greps in the Perl source. NO references (that I could find) on the mod_perl web site. Does anyone know if this is used? If so, where can I look to get an idea of what it is for (my guess is to tell whether or not to pass the environment array to perl_... calls)? it's defined in perl.h. You probably want to read p5p archives to learn why was it added and what it does. I've also found this on google: http://www.google.com.au/search?q=cache:thdxGaHcODcJ:sourceforge.net/developer/diary.php%3Fdiary_id%3D1643%26diary_user%3D3660+USE_ENVIRON_ARRAYhl=enie=UTF-8 __ 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: USE_ENVIRON_ARRAY
- Original Message - From: Stas Bekman [EMAIL PROTECTED] To: Beau E. Cox [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 3:25 PM Subject: Re: USE_ENVIRON_ARRAY Beau E. Cox wrote: Hi - I'm working on an embedding project, and using mod_perl as a tutorial (OK, I'm sometimes blatantly stealing code :)). My tests on a WIN32 box (Win2K) are somewhat flaky. Linux is solid. A grep of mod perl source on WIN32 led me to so pretty strange environment array spoofing based upon #ifdef USE_ENVIRON_ARRAY in modperl_perl.c. ... it's defined in perl.h. You probably want to read p5p archives to learn why was it added and what it does. I've also found this on google: http://www.google.com.au/search?q=cache:thdxGaHcODcJ:sourceforge.net/developer/diary.php%3Fdiary_id%3D1643%26diary_user%3D3660+USE_ENVIRON_ARRAYhl=enie=UTF-8 Thanks Stas, I'll be on my way. (I shudda googled :) ). Aloha = Beau;
Re: [ANNOUNCE] Practical mod_perl is out!
Geoffrey Young wrote: Frank Maas wrote: well, the (long) wait is now over - Practical mod_perl is here. Geoff, you might be the best person to ask and it might be a worthwhile extension to the mod_perl-documentation: why would one use this new book if (s)he has the mod_perl cookbook already. that's a valid question. the way I look at things is like this. mod_perl is in a very unique position. of the three substantial books available on mod_perl, all are useful and authoritative, and all overlap very, very little. for the most part, I would say that the eagle book is best viewed as the main API reference for mod_perl - (almost) all the API functions are explained and illustrated there. it's also a good introductory text on basic Apache functionality and how mod_perl ties into Apache. I think everyone would agree that to do mod_perl you need to own the eagle book. the cookbook tries to show what having the C Apache API at your fingertips really means to Perl programmers. for the most part, it gives lots of examples of using (and abusing) the mod_perl API as a means to extending (and contorting) Apache. there is very little there, for instance, on running and configuring a server, but lots there on programming the deepest recesses of the server. practical mod_perl I think is more of an overall guide to deploying mod_perl services - everything from basic setup and coding to advanced configurations and performance techniques. essentially an overhauled, reworked, and polished Guide, this book has been in the works for a long time, and it contains very valuable information you won't find anywhere else. as I said, you'll find very little overlap between the different books. I know I tried very hard not to duplicate information that you could simply find in the eagle book, and I had advance knowledge of what was in the new book, so I tried not to duplicate information available there either. Stas and Eric I'm sure did the same. I have very little to add to this perfect explanation, other than you really need to have all 3 books on your bookshelf to have a complete mod_perl 1.0 reference. Oh, and Geoff forgot to mention that Practical mod_perl includes two chapters on mod_perl 2.0. I am not trying to set a new war between authors here actually, we're all very much on friendly terms, so a war isn't likely. despite writing through different publishers, we all have the same idea - namely, to promote mod_perl and help document it as best we can. I know that's not something you find in open source every day, but you'll find us all drinking together at OSCon again this year :) Yup, and having 746+600+924=2270 pages of pure mod_perl material, sans index and TOC, in the book stores is a good thing for mod_perl promotion! __ 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: [ANNOUNCE] Practical mod_perl is out!
Geoffrey Young wrote: well, the (long) wait is now over - Practical mod_perl is here. weighing in at a whopping 924 pages, Practical mod_perl really needs no introduction for those that are already familiar with the mod_perl Guide. however, from the ORA catalog description: From writing and debugging scripts to keeping your server running without failures, the techniques in this book will help you squeeze every ounce of power out of your server. True to its title, this is the practical guide to mod_perl. O'Reilly has a sample chapter online http://www.oreilly.com/catalog/pmodperl/chapter/ch06.pdf the book's official website is http://www.modperlbook.org/ where you will find links to ways to purchse the book. A few days later we will put more information on the site, including the source code. Eric is working on it as you read this. kudos Stas and Eric! Thanks Geoff! __ 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: [ANNOUNCE] Practical mod_perl is out!
Ranga Nathan wrote: I have a mod_perl book but I am looking forward to one that includes mod_perl. I believe, corporate IT should take a serious look at using mod_perl. It is time for the heads to come out of the sand. I am interested in creating a presentation for my employer. I need information that reeks (yes I want it to stink) with credibility. Any pointers in this regard is welcome. Archives include quite a few rich threads on mod_perl advocacy: http://perl.apache.org/maillist/modperl.html#Searchable_Archives http://perl.apache.org/maillist/advocacy.html#Searchable_Archives We have this page: http://perl.apache.org/docs/general/advocacy/advocacy.html#top But it certainly could be made much better. Patches are welcome. __ 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
Authentication design
I am trying to design/implement a fairly simple authentication scheme using cookies and such, but wanted to air my design questions before I run into too many issues. I would like the site to be almost entirely publicly accessible, however if you log in you get special options in addition to the normal ones. Also, there are certain things that you can only do while logged in, like post comments. I figure that this is pretty standard. I currently have a PerlAuthenHandler that simply sets the $r-user if either the correct cookie was given or the correct user/pass parameters were passed (remarkably like the cookie authentication listed in the cookbook). It return Apache::OK on all cases except when the user/password parameters are invalid, in which case it redirects the user to the login page. I plan on using the $r-user as a test within my Apache::Registry scripts to see whether the user has successfully logged in and to display the options accordingly. My question basically centers around the best way to protect the only if you login pages. I was thinking of putting them in their own directory and protecting them with a tiny PerlAuthzHandler, which would scatter scripts of the same nature in two separate places (i.e. for comments, view-create-post), or protect the entire site with a PerlAuthzHandler that has a table of all of the only if you login pages, which has the drawback of having to change the handler every time I add a new script. Are there any other/better ways to do this? Thanks -Mike
RE: Authentication design
Hi Michael -- My question basically centers around the best way to protect the only if you login pages. I was thinking of putting them in their own directory and protecting them with a tiny PerlAuthzHandler, which would scatter scripts of the same nature in two separate places (i.e. for comments, view-create-post), or protect the entire site with a PerlAuthzHandler that has a table of all of the only if you login pages, which has the drawback of having to change the handler every time I add a new script. Are there any other/better ways to do this? Using the directory structure is a good way to solve this problem. It is the way Apache likes to work. Most of Apache's internal systems are oriented towards directory paths -- .htaccess, Location, Directory, etc. As a result, there are plenty of facilities for managing security in this fashion. HTH, -Jesse- -- Jesse Erlbaum The Erlbaum Group [EMAIL PROTECTED] Phone: 212-684-6161 Fax: 212-684-6226
[mp2] make test fails to start httpd
1. Problem Description: 'make' test fails to start httpd: $ make test cd src/modules/perl make -f Makefile.modperl make[1]: Nothing to be done for `all'. /usr/local/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -clean *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -clean APACHE_USER= APACHE_GROUP= APACHE_PORT= APACHE= APXS= \ /usr/local/bin/perl -Iblib/arch -Iblib/lib \ t/TEST -verbose=0 *** setting ulimit to allow core files ulimit -c unlimited; t/TEST -verbose=0 /usr/local/apache2/bin/httpd -d /usr/local/src/mod_perl-1.99_09/t -f /usr/local/src/mod_perl-1.99_09/t/conf/httpd.conf -DAPACHE2 using Apache/2.0.46 (prefork MPM) waiting for server to start: ..[Wed Jun 04 00:11:21 2003] [info] 19 Apache:: modules loaded [Wed Jun 04 00:11:21 2003] [info] 3 APR:: modules loaded [Wed Jun 04 00:11:21 2003] [info] base server + 8 vhosts ready to run tests waiting for server to start: giving up after 61 secs !!! server failed to start! (please examine t/logs/error_log) make: *** [run_tests] Error 1 So I examine t/logs/error_log as it suggests: $ cat t/logs/error_log END in modperl_extra.pl, pid=19220 modperl_extra.pl doesn't yield any obvious other places to look for help, so I'm stumped. 2. Used Components and their Configuration: *** using lib/Apache/BuildConfig.pm *** Makefile.PL options: MP_AP_PREFIX = /usr/local/apache2 MP_COMPAT_1X = 1 MP_GENERATE_XS = 1 MP_LIBNAME = mod_perl MP_USE_DSO = 1 MP_USE_STATIC = 1 *** /usr/local/apache2/bin/httpd -V Server version: Apache/2.0.46 Server built: Jun 3 2003 23:00:54 Server's Module Magic Number: 20020903:3 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR=server/mpm/prefork -D APR_HAS_MMAP -D APR_USE_POSIXSEM_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT=/usr/local/apache2 -D SUEXEC_BIN=/usr/local/apache2/bin/suexec -D DEFAULT_PIDLOG=logs/httpd.pid -D DEFAULT_SCOREBOARD=logs/apache_runtime_status -D DEFAULT_LOCKFILE=logs/accept.lock -D DEFAULT_ERRORLOG=logs/error_log -D AP_TYPES_CONFIG_FILE=conf/mime.types -D SERVER_CONFIG_FILE=conf/httpd.conf *** /usr/local/bin/perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=darwin, osvers=6.6, archname=darwin uname='darwin eric-schwartzs-computer.local. 6.6 darwin kernel version 6.6: thu may 1 21:48:54 pdt 2003; root:xnuxnu-344.34.obj~1release_ppc power macintosh powerpc ' config_args='-de -Dprefix=/usr [EMAIL PROTECTED] [EMAIL PROTECTED]' hint=previous, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-pipe -fno-common -no-cpp-precomp -fno-strict-aliasing', optimize='-O3', cppflags='-no-cpp-precomp -pipe -fno-common -no-cpp-precomp -fno-strict-aliasing -pipe -fno-common -no-cpp-precomp -fno-strict-aliasing' ccversion='', gccversion='3.1 20020420 (prerelease)', 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, prototype=define Linker and Libraries: ld='cc', ldflags =' -flat_namespace' libpth=/usr/lib libs=-lm -lc perllibs=-lm -lc libc=/usr/lib/libc.dylib, so=dylib, useshrplib=true, libperl=libperl.dylib gnulibc_version='' Dynamic Linking: dlsrc=dl_dyld.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags=' -flat_namespace -bundle -undefined suppress' Characteristics of this binary (from libperl): Compile-time options: USE_LARGE_FILES Built under darwin Compiled at Jun 1 2003 13:20:13 %ENV: PERL5LIB=/sw/lib/perl5 PERL_LWP_USE_HTTP_10=1 @INC: /sw/lib/perl5/darwin /sw/lib/perl5 /Library/Perl/darwin /Library/Perl /Library/Perl/darwin /Library/Perl /Library/Perl /Network/Library/Perl/darwin /Network/Library/Perl /Network/Library/Perl . This report was generated by -e on Wed Jun 4 06:10:09 2003 GMT.
Re: [mp2] make test fails to start httpd
Eric Schwartz wrote: 1. Problem Description: 'make' test fails to start httpd: [...] waiting for server to start: giving up after 61 secs !!! server failed to start! (please examine t/logs/error_log) [...] *** /usr/local/bin/perl -V Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration: Platform: osname=darwin, osvers=6.6, archname=darwin I don't think it was ever successfully built on darwin. I suppose that the build process may need some tweaking, so somebody with darwin machine and darwin-specific DSO knowledge can take care of this and produce the needed patches which we gladly accept. __ 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
Apache::ReadConfig and method handlers
After a few fruitless days of fiddling with this, I find myself getting nowhere... Can anyone really explain how Apache::ReadConfig and/or direct me to the source code (for handling the namespace, not the code for Perl sections) Issac
Re: UploadMeter
Sorry for the late reply. http://epoch.beamartyr.net/umtest/form.html That's a development version, but there shouldn't be any noticable differences between that and the currect version. It's just configuration issue. One thing I did note is that MSIE 6 is not refreshing the meter... Issac - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, May 31, 2003 7:02 PM Subject: UploadMeter Hi, Anyone know a site that uses UploadMeter? I would like to take a live look at it to see if its what I am after. So far when I try it it simply does not print 'any' form input fields. This is likely due to something about Stacked Handlers. Well TIA. Best Regards, [EMAIL PROTECTED] -- /* Security is a work in progress - dreamwvr */ # 48 69 65 72 6F 70 68 61 6E 74 32 # Note: To begin Journey type man afterboot,man help,man hier[.] # 66 6F 72 20 48 69 72 65 0001 // Who's Afraid of Schrodinger's Cat? /var/(.)?mail/me \? ;-]
RE: UploadMeter
Feature or bug? Other debug info: Apache::Table=HASH(0xa1223ec) Here is what it told me when I used it. Upload Complete Detected upload field: TestUploadField Detected filename: /yame100.zip (320327 bytes) Reported MIME type: application/x-zip-compressed Spool file: /tmp/apreqHHY8vh Other debug info: Apache::Table=HASH(0xa1223ec) -Original Message- From: Issac Goldstand [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 6:04 AM To: [EMAIL PROTECTED] Cc: modperl list Subject: Re: UploadMeter Sorry for the late reply. http://epoch.beamartyr.net/umtest/form.html That's a development version, but there shouldn't be any noticable differences between that and the currect version. It's just configuration issue. One thing I did note is that MSIE 6 is not refreshing the meter... Issac - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, May 31, 2003 7:02 PM Subject: UploadMeter Hi, Anyone know a site that uses UploadMeter? I would like to take a live look at it to see if its what I am after. So far when I try it it simply does not print 'any' form input fields. This is likely due to something about Stacked Handlers. Well TIA. Best Regards, [EMAIL PROTECTED] -- /* Security is a work in progress - dreamwvr */ # 48 69 65 72 6F 70 68 61 6E 74 32 # Note: To begin Journey type man afterboot,man help,man hier[.] # 66 6F 72 20 48 69 72 65 0001 // Who's Afraid of Schrodinger's Cat? /var/(.)?mail/me \? ;-]
Re: UploadMeter
Feature. definately - That page is a seperate module called ApacheUploadMeterTest.pm whose sole purpose is to analyze the upload fields recieved in that request and report all information on them. It's not part of the Apache::UplaodMeter distro at all (Although up till version 0.22 I believe there was a dummy response handler included in it) REmember that the whole library is for the upload progress meter that pops up, not the response page :-) Issac - Original Message - From: Ryan Farrington [EMAIL PROTECTED] Cc: 'modperl list' [EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 2:18 PM Subject: RE: UploadMeter Feature or bug? Other debug info: Apache::Table=HASH(0xa1223ec) Here is what it told me when I used it. Upload Complete Detected upload field: TestUploadField Detected filename: /yame100.zip (320327 bytes) Reported MIME type: application/x-zip-compressed Spool file: /tmp/apreqHHY8vh Other debug info: Apache::Table=HASH(0xa1223ec) -Original Message- From: Issac Goldstand [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2003 6:04 AM To: [EMAIL PROTECTED] Cc: modperl list Subject: Re: UploadMeter Sorry for the late reply. http://epoch.beamartyr.net/umtest/form.html That's a development version, but there shouldn't be any noticable differences between that and the currect version. It's just configuration issue. One thing I did note is that MSIE 6 is not refreshing the meter... Issac - Original Message - From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Saturday, May 31, 2003 7:02 PM Subject: UploadMeter Hi, Anyone know a site that uses UploadMeter? I would like to take a live look at it to see if its what I am after. So far when I try it it simply does not print 'any' form input fields. This is likely due to something about Stacked Handlers. Well TIA. Best Regards, [EMAIL PROTECTED] -- /* Security is a work in progress - dreamwvr */ # 48 69 65 72 6F 70 68 61 6E 74 32 # Note: To begin Journey type man afterboot,man help,man hier[.] # 66 6F 72 20 48 69 72 65 0001 // Who's Afraid of Schrodinger's Cat? /var/(.)?mail/me \? ;-]
[OT] CGI::Push
Does anyone have success/failure stories using Push responses? Please share. Thanks. Issac
