Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)
Bill Marrs wrote: Try this patch: [...] Feel free to submit this bug report and the fix to httpd-dev. Please let me know if you do that, so I won't duplicate it. But I'd prefer that you do it so you can make sure that it gets fixed in the next release, since you need it working. I've just verified that your patch fixes my problem. Great! I've never submitted a but report and fix to httpd-dev, but I'm willing to do it. How do I do it? Open a bugzilla account and add a new bug report: http://httpd.apache.org/bug_report.html Please report to the list the bug id so we can document this issue for those who have the same problem with older httpds. Thanks. __ 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 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)
Please report to the list the bug id so we can document this issue for those who have the same problem with older httpds. Thanks. OK, I've posted it. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22259 Thanks for the fix! -bill
Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)
Try this patch: [...] Feel free to submit this bug report and the fix to httpd-dev. Please let me know if you do that, so I won't duplicate it. But I'd prefer that you do it so you can make sure that it gets fixed in the next release, since you need it working. I've just verified that your patch fixes my problem. I've never submitted a but report and fix to httpd-dev, but I'm willing to do it. How do I do it? -bill
Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)
Bill Marrs wrote: Please report to the list the bug id so we can document this issue for those who have the same problem with older httpds. Thanks. OK, I've posted it. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22259 Thanks for the fix! For the archives: This bug has been fixed in the current httpd-2.0 cvs, and will be also in the soon to be released 2.0.48. __ 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 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)
Bill Marrs wrote:
[...]
You would probably wish to append your script with
additional output after the empty string? Something like:
#!/usr/bin/perl
$|=1;
print "Content-Type: text/html\n\n";
print "hello world";
# This line causes the error (?)
print "";
print "hello again";
---
When I do this, the mod_perl variant of the script fails to print "hello
again".
mod_cgi prints everything just fine and gets no errors.
I changed my test script to print a bunch of `date`'s
http://shevek.kenyonhill.com/cgi/test.pl
http://shevek.kenyonhill.com/perl/test.pl
Sorry for getting late to this thread, this is a bug in mod_deflate. You don't
see it in mod_cgi, because mod_cgi doesn't really handle buffering and
flushing, since it just reads the data from the pipe to the process.
mod_deflate didn't follow the deflate() spec, saying that the caller shouldn't
call deflate, when there is no data to deflate. Try this patch:
Index: modules/filters/mod_deflate.c
===
RCS file: /home/cvs/httpd-2.0/modules/filters/mod_deflate.c,v
retrieving revision 1.26.2.5
diff -u -r1.26.2.5 mod_deflate.c
--- modules/filters/mod_deflate.c 17 May 2003 18:27:43 - 1.26.2.5
+++ modules/filters/mod_deflate.c 5 Aug 2003 06:37:59 -
@@ -529,9 +529,11 @@
if (APR_BUCKET_IS_FLUSH(e)) {
apr_bucket *bkt;
-zRC = deflate(&(ctx->stream), Z_SYNC_FLUSH);
-if (zRC != Z_OK) {
-return APR_EGENERAL;
+if (ctx->stream.avail_in > 0) {
+zRC = deflate(&(ctx->stream), Z_SYNC_FLUSH);
+if (zRC != Z_OK) {
+return APR_EGENERAL;
+ }
}
ctx->stream.next_out = ctx->buffer;
Feel free to submit this bug report and the fix to httpd-dev. Please let me
know if you do that, so I won't duplicate it. But I'd prefer that you do it so
you can make sure that it gets fixed in the next release, since you need it
working.
__
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::ProxyRewrite possible bug with port numbers on ProxyRewrite
I've been kicking around a proxy server here and found your Apache-ProxyRewrite most useful but I have this quirk perhaps you can help with. I'm using version 0.17. I've read in the ChangeLog that one of the more recent fixes (v0.16) may have been to address the problem I'm encountering. Seems as though the ProxyTo doesn't have any trouble with http://host:12345 and the automatic mappings with the same host:port. The ProxyRewrite on the other hand doesn't work with host:port. It's as if the pattern matching goes out to lunch, gets amnesia.. something. I've also noticed that if I have multiple ProxyRewrite statements the last one (provide there's no port number) is the only one being processed. Thanks! Dwayne * * Dwayne Turley, Sr. System Administrator, Code 589 (Wallops) * Real Time Software Engineering Branch * Building N161, Wallops Island VA 23337 * Phone: 757 824 1135 Fax: 757 824 1903 * mailto:[EMAIL PROTECTED] * "We all know Linux is great...it does infinite loops in 5 seconds." -- Linus Windows: Where do you want to go today? MacOS: Where do you want to be tomorrow? Linux: Are you coming or what? Windows is not the answer. Windows is the question. "No," is the answer.
Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)
> Well, the problem is that I get this error in my error_log: > > [Mon Jul 21 14:18:55 2003] [error] 4297: ModPerl::RegistryBB: 20014:Error > string not specified yet at /var/www/perl/test.pl line 6. > > Also, more important, the script seems to be terminating and/or any output > following the 'print ""' is not sent to the client as far as I can tell. This is another story! You have a problem with ModPerl::RegistryBB. HTTP log can't help if ModPerl::RegistryBB aborts at that point. From my point of view it is supposed to be a warning (or debug/warning) instead of the error in ModPerl::RegistryBB, because it could be necessary sometimes to flush empty string (for example, to overwrite the default chunking behavior of core Apache). Unfortunately, I can't look into the sources of Apache-2 now. Can somebody help to patch this problem on Bill's machine first in order to let us to go ahead with this research? Thanks, Slava
Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)
We can see that mod_cgi bufferizes the output and sends it with Content-Length HTTP header (to mod_deflate). Indeed mod_perl generates chunked response. Finally we have the same result. I don't see any problem at this moment. Well, the problem is that I get this error in my error_log: [Mon Jul 21 14:18:55 2003] [error] 4297: ModPerl::RegistryBB: 20014:Error string not specified yet at /var/www/perl/test.pl line 6. Also, more important, the script seems to be terminating and/or any output following the 'print ""' is not sent to the client as far as I can tell. You would probably wish to append your script with additional output after the empty string? Something like: #!/usr/bin/perl $|=1; print "Content-Type: text/html\n\n"; print "hello world"; # This line causes the error (?) print ""; print "hello again"; --- When I do this, the mod_perl variant of the script fails to print "hello again". mod_cgi prints everything just fine and gets no errors. I changed my test script to print a bunch of `date`'s http://shevek.kenyonhill.com/cgi/test.pl http://shevek.kenyonhill.com/perl/test.pl It may cause a problem for chunked output if mod_deflate does not care to keep internal buffer and check its size when flushing... I may not be understanding the output you sent or what you're saying, but I still don't follow why this would be a mod_deflate bug if mod_cgi with the same script has no problem.
Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)
Well, let's see: ==> (93.530) Outgoing Request http://shevek.kenyonhill.com/cgi/test.pl HTTP/1.1> C05 --> S06 GET /cgi/test.pl HTTP/1.1 C05 --> S06 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/msword, */* C05 --> S06 Accept-Language: en-us C05 --> S06 Accept-Encoding: gzip, deflate C05 --> S06 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98) C05 --> S06 Host: shevek.kenyonhill.com C05 --> S06 Accept-Charset: ISO-8859-1 == Body was 0 bytes == C05 <-- S06 HTTP/1.1 200 OK C05 <-- S06 Date: Mon, 21 Jul 2003 16:30:59 GMT C05 <-- S06 Server: Apache C05 <-- S06 Vary: Accept-Encoding,User-Agent C05 <-- S06 Content-Encoding: gzip C05 <-- S06 Content-Length: 34 C05 <-- S06 Connection: close C05 <-- S06 Content-Type: text/html; charset=ISO-8859-1 C05 <-- S06 == Incoming Body was 34 bytes == == real URL = http://shevek.kenyonhill.com/cgi/test.pl == == Transmission: text gzip == == (93.640) Response 200 to http://shevek.kenyonhill.com/cgi/test.pl HTTP/1.1> == Latency = 0.110 seconds, Extra Delay = 0.000 seconds == Restored Body was 14 bytes == == Content Begin: == hello world == Content End == ==> (164.770) Outgoing Request http://shevek.kenyonhill.com/perl/test.pl HTTP/1.1> C05 --> S06 GET /perl/test.pl HTTP/1.1 C05 --> S06 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/msword, */* C05 --> S06 Accept-Language: en-us C05 --> S06 Accept-Encoding: gzip, deflate C05 --> S06 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98) C05 --> S06 Host: shevek.kenyonhill.com C05 --> S06 Accept-Charset: ISO-8859-1 == Body was 0 bytes == C05 <-- S06 HTTP/1.1 200 OK C05 <-- S06 Date: Mon, 21 Jul 2003 16:32:11 GMT C05 <-- S06 Server: Apache C05 <-- S06 Vary: Accept-Encoding,User-Agent C05 <-- S06 Content-Encoding: gzip C05 <-- S06 Connection: close C05 <-- S06 Transfer-Encoding: chunked C05 <-- S06 Content-Type: text/html; charset=ISO-8859-1 C05 <-- S06 == Incoming Body was 629 bytes == == real URL = http://shevek.kenyonhill.com/perl/test.pl == == Transmission: text gzip chunked == == Chunk Log == 1e (hex) = 30 (dec) 245 (hex) = 581 (dec) 0 (hex) = 0 (dec) == (164.880) Response 200 to http://shevek.kenyonhill.com/perl/test.pl HTTP/1.1> == Latency = 0.110 seconds, Extra Delay = 0.000 seconds == Restored Body was 14 bytes == == Content Begin: == hello world == Content End == We can see that mod_cgi bufferizes the output and sends it with Content-Length HTTP header (to mod_deflate). Indeed mod_perl generates chunked response. Finally we have the same result. I don't see any problem at this moment. You would probably wish to append your script with additional output after the empty string? Something like: #!/usr/bin/perl $|=1; print "Content-Type: text/html\n\n"; print "hello world"; # This line causes the error (?) print ""; print "hello again"; --- It may cause a problem for chunked output if mod_deflate does not care to keep internal buffer and check its size when flushing... Thanks, Slava - Original Message - From: "Bill Marrs" <[EMAIL PROTECTED]> To: "Slava Bizyayev" <[EMAIL PROTECTED]>; "Stas Bekman" <[EMAIL PROTECTED]>; "Philippe M. Chiasson" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, July 21, 2003 6:49 AM Subject: Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified) > > >I can measure it myself if you can provide me with URLs to your resources > >and identify them in terms of which one is mod_CGI and which is mod_perl. > > This is the mod_cgi one that works fine, no errors: > http://shevek.kenyonhill.com/cgi/test.pl > > This is the mod_perl one (same script) that generates the "20014:Error" in > the error_log. Also, the page doesn't display correctly (it seems to erase > itself): > > http://shevek.kenyonhill.com/perl/test.pl > > This is the contents of test.pl: > > --- > #!/usr/bin/perl > $|=1; > print "Content-Type: text/html\n\n"; > print "hello world"; > # This line causes the error > print ""; > --- > > Let me know if you need anything more. > >
Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)
I can measure it myself if you can provide me with URLs to your resources and identify them in terms of which one is mod_CGI and which is mod_perl. This is the mod_cgi one that works fine, no errors: http://shevek.kenyonhill.com/cgi/test.pl This is the mod_perl one (same script) that generates the "20014:Error" in the error_log. Also, the page doesn't display correctly (it seems to erase itself): http://shevek.kenyonhill.com/perl/test.pl This is the contents of test.pl: --- #!/usr/bin/perl $|=1; print "Content-Type: text/html\n\n"; print "hello world"; # This line causes the error print ""; --- Let me know if you need anything more.
Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)
It is supposed to be something like the following: C05 --> S06 GET /html/wowtmovie.html HTTP/1.1 C05 --> S06 Accept: */* C05 --> S06 Accept-Language: en-us C05 --> S06 Accept-Encoding: gzip, deflate C05 --> S06 User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows 98) C05 --> S06 Host: devl4.outlook.net C05 --> S06 Pragma: no-cache C05 --> S06 Accept-Charset: ISO-8859-1 == Body was 0 bytes == C05 <-- S06 HTTP/1.1 200 OK C05 <-- S06 Date: Fri, 31 May 2002 17:36:57 GMT C05 <-- S06 Server: Apache/1.3.22 (Unix) Debian GNU/Linux mod_perl/1.26 C05 <-- S06 X-Module-Sender: Apache::Dynagzip C05 <-- S06 Transfer-Encoding: chunked C05 <-- S06 Expires: Friday, 31-May-2002 17:41:57 GMT C05 <-- S06 Vary: Accept-Encoding C05 <-- S06 Content-Type: text/html; charset=iso-8859-1 C05 <-- S06 Content-Encoding: gzip C05 <-- S06 == Incoming Body was 9411 bytes == == Transmission: text gzip chunked == == Chunk Log == a (hex) = 10 (dec) 1314 (hex) = 4884 (dec) 3ed (hex) = 1005 (dec) 354 (hex) = 852 (dec) 450 (hex) = 1104 (dec) 5e6 (hex) = 1510 (dec) 0 (hex) = 0 (dec) == Latency = 0.170 seconds, Extra Delay = 0.440 seconds == Restored Body was 149208 bytes == Not necessarily the same... To measure it you might want to use a proxy, or a sniffer. I can measure it myself if you can provide me with URLs to your resources and identify them in terms of which one is mod_CGI and which is mod_perl. Thanks, Slava - Original Message - From: "Bill Marrs" <[EMAIL PROTECTED]> To: "Slava Bizyayev" <[EMAIL PROTECTED]>; "Stas Bekman" <[EMAIL PROTECTED]>; "Philippe M. Chiasson" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Sunday, July 20, 2003 6:22 PM Subject: Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified) > At 11:07 AM 7/19/2003, Slava Bizyayev wrote: > >May I see your client side HTTP log of the request-response transaction > >through mod_cgi vs. mod_perl? > > I'm not sure what you mean. Do you mean my access_log? I have a > deflate_log as well (that shows the compression stats as well). But, maybe > you're talking about something else? If so, how do I get what you want? > > >
Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)
At 11:07 AM 7/19/2003, Slava Bizyayev wrote: May I see your client side HTTP log of the request-response transaction through mod_cgi vs. mod_perl? I'm not sure what you mean. Do you mean my access_log? I have a deflate_log as well (that shows the compression stats as well). But, maybe you're talking about something else? If so, how do I get what you want?
Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)
May I see your client side HTTP log of the request-response transaction through mod_cgi vs. mod_perl? Thanks, Slava - Original Message - From: "Bill Marrs" <[EMAIL PROTECTED]> To: "Slava Bizyayev" <[EMAIL PROTECTED]>; "Stas Bekman" <[EMAIL PROTECTED]>; "Philippe M. Chiasson" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Saturday, July 19, 2003 7:01 AM Subject: Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified) > At 07:16 PM 7/18/2003, Slava Bizyayev wrote: > >In my understanding _it is_ a problem of mod_deflate. > > The error does not occur if I run the same test script under mod_cgi > instead of mod_perl. This suggests that the problem is in mod_perl not > mod_deflate. > > right? > > >
Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)
At 07:16 PM 7/18/2003, Slava Bizyayev wrote: In my understanding _it is_ a problem of mod_deflate. The error does not occur if I run the same test script under mod_cgi instead of mod_perl. This suggests that the problem is in mod_perl not mod_deflate. right?
Re: clones and parents (bug report)
Randy Kobes wrote: [..] Just to verify, I also get this with ActivePerl 806, Apache/2.0.47, and the current mod_perl cvs version. Here's some partial debug information: PERL58! 28083490() PERL58! 280648b5() and what are these two perl calls? modperl_perl_destruct(interpreter * 0x0089c794): line 130 + 9 bytes: modperl_perl.c Perhaps the interpreter struct is corrupt? modperl_interp_destroy(modperl_interp_t * 0x008a47c8): line 128 + 12 bytes: modperl_interp.c modperl_interp_pool_destroy(void * 0x00869b78): line 184 + 12 bytes: modperl_interp.c run_cleanups(cleanup_t * * 0x0089a7a8): line 1980: httpd-2.0.47\srclib\apr\memory\unix\apr_pools.c apr_pool_destroy(apr_pool_t * 0x00401585): line 758: httpd-2.0.47\srclib\apr\memory\unix\apr_pools.c main(int 0x00401d82, const char * const * 0x0001) line 619 APACHE! mainCRTStartup + 227 bytes KERNEL32! 77e7eb69() === -- __ 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: clones and parents (bug report)
On Fri, 18 Jul 2003, Marc M. Adkins wrote: > > -8<-- Start Bug Report 8<-- > 1. Problem Description: > > # Problem: When I add PerlOptions +Parent I get a segfault. > # > # Breaks with: > # Windows 2000 SP2 > # Apache 2.0.46 > # ActiveState Perl 5.8.0 (build 804) > # mod_perl 1.99.10dev(installed using mpinstall.pl, > # re-installed TODAY to be safe) > # > # C:\Apache2\conf\parental.conf > LoadFileC:/Perl/bin/perl58.dll > LoadModule perl_module modules/mod_perl.so > ### > # > # Setup for named virtual hosts on port 80: > # > > NameVirtualHost *:80 > Listen 80 > > ### > > > ServerNamelocalhost:80 > ServerAdmin [EMAIL PROTECTED] > DocumentRoot C:/Apache2/htdocs > PerlOptions +Parent > PerlSwitches -wT > Just to verify, I also get this with ActivePerl 806, Apache/2.0.47, and the current mod_perl cvs version. Here's some partial debug information: PERL58! 28083490() PERL58! 280648b5() modperl_perl_destruct(interpreter * 0x0089c794): line 130 + 9 bytes: modperl_perl.c modperl_interp_destroy(modperl_interp_t * 0x008a47c8): line 128 + 12 bytes: modperl_interp.c modperl_interp_pool_destroy(void * 0x00869b78): line 184 + 12 bytes: modperl_interp.c run_cleanups(cleanup_t * * 0x0089a7a8): line 1980: httpd-2.0.47\srclib\apr\memory\unix\apr_pools.c apr_pool_destroy(apr_pool_t * 0x00401585): line 758: httpd-2.0.47\srclib\apr\memory\unix\apr_pools.c main(int 0x00401d82, const char * const * 0x0001) line 619 APACHE! mainCRTStartup + 227 bytes KERNEL32! 77e7eb69() === -- best regards, randy kobes
RE: clones and parents (bug report)
-8<-- Start Bug Report 8<-- 1. Problem Description: # Problem: When I add PerlOptions +Parent I get a segfault. # # Breaks with: # Windows 2000 SP2 # Apache 2.0.46 # ActiveState Perl 5.8.0 (build 804) # mod_perl 1.99.10dev(installed using mpinstall.pl, # re-installed TODAY to be safe) # # Pops up "Apache.exe - Application Error" box: # The instruction at "0x280830ed" # referenced memory at "0x". # The memory could not be "written". # # After killing the box the command line says: # C:\Apache2\bin> apache # Starting Apache... # and must be killed via . The error log is empty. # # In at least one case the Apache.exe process refused to stop # and COULD NOT BE SHUT DOWN VIA TASK MANAGER, requiring reboot. # This seems to happen when is not invoked immediately # after cancelling the message box. 2. Used Components and their Configuration: *** mod_perl version 1.9910 *** using C:/Perl/site/lib/Apache/BuildConfig.pm *** Makefile.PL options: MP_AP_PREFIX=> \Apache2 MP_COMPAT_1X=> 1 MP_GENERATE_XS => 1 MP_INST_APACHE2 => 1 MP_LIBNAME => mod_perl MP_USE_DSO => 1 MP_USE_STATIC => 1 *** \Apache2/bin/Apache.exe -V Server version: Apache/2.0.46 Server built: May 27 2003 23:15:42 Server's Module Magic Number: 20020903:3 Architecture: 32-bit Server compiled with -D APACHE_MPM_DIR="server/mpm/winnt" -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT="/apache" -D SUEXEC_BIN="/apache/bin/suexec" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_ERRORLOG="logs/error.log" -D AP_TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/httpd.conf" *** C:\Perl\bin\perl.exe -V Summary of my perl5 (revision 5 version 8 subversion 0) configuration: Platform: osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef usethreads=undef 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='cl', ccflags ='-nologo -Gf -W3 -MD -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES _FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSV CRT_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:\Perl\lib\CORE" -machine:x86' libpth="C:\Program Files\Microsoft.Net\Odbc.Net\" "C:\Perl\lib\CORE" libs= 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= 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=' ', ddlflags='-dll -nologo -nodefaultlib -release -libpath:"C:\Perl\lib\CORE" -machine:x86' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT PERL_IMPLICIT_SYS Locally applied patches: ActivePerl Build 804 Built under MSWin32 Compiled at Dec 1 2002 23:15:13 %ENV: PERL_LWP_USE_HTTP_10="1" @INC: C:/Perl/lib C:/Perl/site/lib . 3. This is the core dump trace: (if you get a core dump): # I don't have anything built with debug but even so the stack shows: # PERL58.DLL # PERL58.DLL # MOD_PERL.DLL # when I pop into the debugger from the alert panel. This report was generated by -e on Fri Jul 18 23:48:59 2003 GMT. -8<-- End Bug Report --8<--
Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)
Hi guys, In my understanding _it is_ a problem of mod_deflate. It's a bit tricky to flush dynamically generated content over HTTP/1.1: Core Apache marks the end of your document with empty chunk. When you flush an empty string in the middle of your document Apache has no way to serve your directions, but to create an empty chunk immediately. The first empty chunk received by the client is recognized as the end of the document. The rest of the data stream is just ignored. I didn't have a chance to look into the source of mod_deflate yet, but this definitely has to be taken into account over there. In my understanding it would be the best our bet just to bring this issue to the attention of the author of mod_deflate. It's supposed to be easy to fix. Thanks, Slava - Original Message - From: "Stas Bekman" <[EMAIL PROTECTED]> To: "Philippe M. Chiasson" <[EMAIL PROTECTED]> Cc: "Bill Marrs" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, July 15, 2003 3:24 AM Subject: Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified) > Philippe M. Chiasson wrote: > > On Thu, 2003-07-03 at 01:24, Bill Marrs wrote: > > > >>This fixed the bug for me. > > > > > > Great! Will commit it in the near future. (Can't seem to access the cvs > > server right now, crappy internet cafe) > > -1, this is a wrong solution. print ""; should flush just like it did in > mod_perl 1.0 if $| == 1; Consider this script: > > print "Content-type: text/plain\n\n"; > local $| = 0; > print "start\n\n"; > local $| = 1; > print ""; > sleep 5; > local $| = 0; > print "end\n"; > > print "", must immediately flush the buffered data, since $| has changed from > 0 to 1. > > > > One thing that could help is if someone could take the time to write a > > test for this bug. > > Unfortunately I don't seem to be able to reproduce the problem, so I can't > debug the problem. It could be a bug on the mod_deflate's behalf as well. > Philippe, were you able to reproduce the problem with Bill's setup? I was > writing a test, but couldn't get it to fail... may be because i was using > 2.0.47. Bill, do you have the problem with the latest apache version? > > Also Bill, why do you have this setup: > > >AddOutputFilterByType DEFLATE text/* >SetOutputFilter DEFLATE > > > why adding it twice? You need only the latter inside , or > alternatively only the former outside if you want it to be set > globally: > http://httpd.apache.org/docs-2.0/mod/core.html#addoutputfilterbytype > > __ > 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 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)
I could upgrade to 2.0.47, but it seems unlikely that it would fix
this. Are you sure you're running a mod_perl without Philippe's fix (in
Apache__RequestIO.h), I assumed he eventually checked it in.
No, Philippe hasn't committed it, neither I have used it. If you can test
with 2.9.47 that will help. Otherwise I'll later try with .46 as well.
I just upgraded to Apache 2.0.47 and the latest CVS of mp2 and I'm
reproducing it, same as I originally reported.
I tried a few variations to see if I could find other factors, but didn't
have much luck. The server I'm testing on is live (runs a small site), so
I'm somewhat limited in what I can do. But, I tried removing mod_rewrite,
and mod_ssl from my server config and I still got the error in my tests.
I also tried varying the mod_deflate config (as you pointed out it was
redundant/wrong)...
Also Bill, why do you have this setup:
AddOutputFilterByType DEFLATE text/*
SetOutputFilter DEFLATE
why adding it twice? You need only the latter inside , or
alternatively only the former outside if you want it to be
set globally:
http://httpd.apache.org/docs-2.0/mod/core.html#addoutputfilterbytype
Ah, I misunderstood the mod_deflate docs. I think at the time, it didn't
seem to work with just one of them in-place, so I added the
other. *SHRUG* I can't say I'm a pro at Apache config files, I just
tinker until it works. I assume this is irrelevant to the bug, though.
I'm not sure if your config doesn't insert the filter twice. Need to check
whether SetOutputFilter overrides AddOutputFilterByType as well.
In my config, I have a deflate log:
DeflateFilterNote Input instream
DeflateFilterNote Output outstream
DeflateFilterNote Ratio ratio
LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%) "%{User-agent}i"'
deflate
CustomLog /var/log/httpd/deflate_log deflate
I was using this to verify that deflate was active or not. What I found
was that using "AddOutputFilterByType DEFLATE text/*" doesn't seem to
activate deflate, no matter where I put it (in a or at the
top-level of the config). My deflate log shows that no compression is
occurring. "SetOutputFilter DEFLATE" does activate deflate globally (for
all locations), no matter where I put it. I'm afraid I don't find the
mod_deflate docs very clear on placement.
When you were trying to reproduce, I don't know if you used my (redundant)
config before, but if you only used "AddOutputFilterByType DEFLATE text/*",
and not "SetOutputFilter DEFLATE", that might explain why you were not able
to reproduce this, I don't think that activates deflate (at least that's
what my deflate_log shows for me).
Otherwise, if you're still not reproducing this, I would assume there's
some difference in the way we are building apache or our apache config
files or perl?
Here's my Apache Configure line:
./configure --enable-modules=all --enable-mods-shared=all --enable-deflate
--with-mpm=prefork --enable-rewrite --enable-ssl
Here are the Modules I load:
LoadModule cgi_module modules/mod_cgi.so
LoadModule access_module modules/mod_access.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule env_module modules/mod_env.so
LoadModule expires_module modules/mod_expires.so
LoadModule headers_module modules/mod_headers.so
LoadModule setenvif_module modules/mod_setenvif.so
LoadModule mime_module modules/mod_mime.so
LoadModule autoindex_module modules/mod_autoindex.so
LoadModule asis_module modules/mod_asis.so
LoadModule info_module modules/mod_info.so
LoadModule vhost_alias_module modules/mod_vhost_alias.so
LoadModule dir_module modules/mod_dir.so
LoadModule alias_module modules/mod_alias.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule perl_module modules/mod_perl.so
LoadModule ssl_module modules/mod_ssl.so
mod_cgi, mod_ssl and mod_rewrite seem to be innocent (when I removed them,
it still failed), but maybe you're using a module that I'm not and this is
causing your config to work better? I think that I'm loading less modules
than what is typical, I removed as many as I could to reduce memory usage a
while ago.
*SHRUG*
One thing that may be relevant is tracking down where the "20014:Error" is
coming from. Web searching seems to associate it with Berkeley DB code,
which seems odd to me, is Apache using Berkeley DB code somewhere (via a
filter?)?
This isn't a very important issue for me. I have a decent workaround
(print " " instead of ""), plus I'm not really able to use mod_deflate that
much anyway because it puts too much load on my server (mod_gzip with
Apache 1.3 worked better for me).
Thanks
-bill
Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error stringnot specified)
Bill Marrs wrote: At 04:24 AM 7/15/2003, Stas Bekman wrote: Philippe M. Chiasson wrote: On Thu, 2003-07-03 at 01:24, Bill Marrs wrote: This fixed the bug for me. Great! Will commit it in the near future. (Can't seem to access the cvs server right now, crappy internet cafe) -1, this is a wrong solution. print ""; should flush just like it did in mod_perl 1.0 if $| == 1; Consider this script: print "Content-type: text/plain\n\n"; local $| = 0; print "start\n\n"; local $| = 1; print ""; sleep 5; local $| = 0; print "end\n"; print "", must immediately flush the buffered data, since $| has changed from 0 to 1. This may be naive, but might it not flush the output buffer at the 4th line (local $| = 1;)? ...or does the flush only happen when print is called. Having to call print "" seems cumbersome to do a flush, but maybe that's just the way Perl works? There is $r->rflush for this purpose. This is not a perl API, but Apache API. You can also use IO::File or other IO packages that extend perl to provide this kind of API. But this is how perl works, so we have to preserve it under mod_perl. One thing that could help is if someone could take the time to write a test for this bug. Unfortunately I don't seem to be able to reproduce the problem, so I can't debug the problem. It could be a bug on the mod_deflate's behalf as well. Philippe, were you able to reproduce the problem with Bill's setup? I was writing a test, but couldn't get it to fail... may be because i was using 2.0.47. Bill, do you have the problem with the latest apache version? Did you see my note in the original post about this working fine under mod_cgi, but causing the "20014:Error" only under mod_perl? This seemed to point the finger squarely at mod_perl. If I was able to reproduce it I could tell, but I don't seem to. I could upgrade to 2.0.47, but it seems unlikely that it would fix this. Are you sure you're running a mod_perl without Philippe's fix (in Apache__RequestIO.h), I assumed he eventually checked it in. No, Philippe hasn't committed it, neither I have used it. If you can test with 2.9.47 that will help. Otherwise I'll later try with .46 as well. Also Bill, why do you have this setup: AddOutputFilterByType DEFLATE text/* SetOutputFilter DEFLATE why adding it twice? You need only the latter inside , or alternatively only the former outside if you want it to be set globally: http://httpd.apache.org/docs-2.0/mod/core.html#addoutputfilterbytype Ah, I misunderstood the mod_deflate docs. I think at the time, it didn't seem to work with just one of them in-place, so I added the other. *SHRUG* I can't say I'm a pro at Apache config files, I just tinker until it works. I assume this is irrelevant to the bug, though. I'm not sure if your config doesn't insert the filter twice. Need to check whether SetOutputFilter overrides AddOutputFilterByType as well. __ 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 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)
At 04:24 AM 7/15/2003, Stas Bekman wrote: Philippe M. Chiasson wrote: On Thu, 2003-07-03 at 01:24, Bill Marrs wrote: This fixed the bug for me. Great! Will commit it in the near future. (Can't seem to access the cvs server right now, crappy internet cafe) -1, this is a wrong solution. print ""; should flush just like it did in mod_perl 1.0 if $| == 1; Consider this script: print "Content-type: text/plain\n\n"; local $| = 0; print "start\n\n"; local $| = 1; print ""; sleep 5; local $| = 0; print "end\n"; print "", must immediately flush the buffered data, since $| has changed from 0 to 1. This may be naive, but might it not flush the output buffer at the 4th line (local $| = 1;)? ...or does the flush only happen when print is called. Having to call print "" seems cumbersome to do a flush, but maybe that's just the way Perl works? One thing that could help is if someone could take the time to write a test for this bug. Unfortunately I don't seem to be able to reproduce the problem, so I can't debug the problem. It could be a bug on the mod_deflate's behalf as well. Philippe, were you able to reproduce the problem with Bill's setup? I was writing a test, but couldn't get it to fail... may be because i was using 2.0.47. Bill, do you have the problem with the latest apache version? Did you see my note in the original post about this working fine under mod_cgi, but causing the "20014:Error" only under mod_perl? This seemed to point the finger squarely at mod_perl. I could upgrade to 2.0.47, but it seems unlikely that it would fix this. Are you sure you're running a mod_perl without Philippe's fix (in Apache__RequestIO.h), I assumed he eventually checked it in. Also Bill, why do you have this setup: AddOutputFilterByType DEFLATE text/* SetOutputFilter DEFLATE why adding it twice? You need only the latter inside , or alternatively only the former outside if you want it to be set globally: http://httpd.apache.org/docs-2.0/mod/core.html#addoutputfilterbytype Ah, I misunderstood the mod_deflate docs. I think at the time, it didn't seem to work with just one of them in-place, so I added the other. *SHRUG* I can't say I'm a pro at Apache config files, I just tinker until it works. I assume this is irrelevant to the bug, though. -bill
Re: [MP2 - BUG ?] Issue handing Apache config. error messages
Issac Goldstand wrote: [...] (Starting with mor_perl 2)... I'm toying with the idea of starting the porting tutorial, but I want to make sure it's written well for clueless people (which I probably still at least half count as :-)) and with accurate content. porting or starting? We already have a porting guide: http://perl.apache.org/docs/2.0/user/porting/porting.html a porting reference: http://perl.apache.org/docs/2.0/user/porting/compat.html Right - I read it, and it's reference. It's not a good guide. A guide should start with the basics. The mp_1 guide is one of the most beautiful pieces of electronic documentation in existance! It should be a book (I know: practical mod_perl) Seriously though - the guide is what personally turned me on to mod_perl, but the above two documents make me shiver and stay the hell away from mp_2. What's needed is a good friendly piece of documentation to get people moving... to mp_2 Certainly. Just remember that the guide is 4 years old. The 2.0 docs are a few months old. So all we need is to make it better. and even getting started: http://perl.apache.org/docs/2.0/user/intro/start_fast.html Will look at it shortly - Let's not bite off more than we can chew in one mouthful. I'd suggest to improve these docs where approapriate and start a new doc only if it really doesn't fit into the existing docs. I'm just not sure if it *does* fit... Let's see what you come up with and we can decides whether it fits or not. The idea is to avoid forks and have people collaborate on the single best source of documentation, rather than private projects. Private projects could be good, but given the complexity of mod_perl, having a good single source of documentation is a great boon for its acceptance. __ 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 - BUG ?] Issue handing Apache config. error messages
- Original Message - From: "Stas Bekman" <[EMAIL PROTECTED]> To: "Issac Goldstand" <[EMAIL PROTECTED]> > Issac Goldstand wrote: > > Looking at it now, I tend to agree... I just have a vague recollection of > > my first mod_perl 2 handler (Written only 2 weeks ago, though I dabbled with > > the C API 9 months ago, already) and reading it and playing with httpd.conf > > and overall being very confused. > > I've just committed the examples, hopefully they will appear online soon. > > > I'd consider having 2 guides written - a porting guide - yours is nice, but > > more as reference than as tutorial - and the second for newbies (Starting > > with mor_perl 2)... I'm toying with the idea of starting the porting > > tutorial, but I want to make sure it's written well for clueless people > > (which I probably still at least half count as :-)) and with accurate > > content. > > porting or starting? We already have a porting guide: > http://perl.apache.org/docs/2.0/user/porting/porting.html > > a porting reference: > http://perl.apache.org/docs/2.0/user/porting/compat.html > Right - I read it, and it's reference. It's not a good guide. A guide should start with the basics. The mp_1 guide is one of the most beautiful pieces of electronic documentation in existance! It should be a book (I know: practical mod_perl) Seriously though - the guide is what personally turned me on to mod_perl, but the above two documents make me shiver and stay the hell away from mp_2. What's needed is a good friendly piece of documentation to get people moving... to mp_2 > and even getting started: > http://perl.apache.org/docs/2.0/user/intro/start_fast.html Will look at it shortly - Let's not bite off more than we can chew in one mouthful. > I'd suggest to improve these docs where approapriate and start a new doc only > if it really doesn't fit into the existing docs. I'm just not sure if it *does* fit... Issac
Re: [MP2 - BUG ?] Issue handing Apache config. error messages
Issac Goldstand wrote: Right. Could you possibly clarify the difference between SetHandler perl-script and SetHandler modperl? I'm still not sure I've got the straight of it yet... You must be kidding ;) Have you read the sections at the URL posted below? Stas Bekman wrote: Sreeji K Das wrote: [...] You need to use 'SetHandler perl-script' for that, see: http://perl.apache.org/docs/2.0/user/config/config.html#C_SetHandler_ __ 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 Patch] BUG with mod_deflate and $|=1 (20014:Error stringnot specified)
Philippe M. Chiasson wrote: On Thu, 2003-07-03 at 01:24, Bill Marrs wrote: This fixed the bug for me. Great! Will commit it in the near future. (Can't seem to access the cvs server right now, crappy internet cafe) -1, this is a wrong solution. print ""; should flush just like it did in mod_perl 1.0 if $| == 1; Consider this script: print "Content-type: text/plain\n\n"; local $| = 0; print "start\n\n"; local $| = 1; print ""; sleep 5; local $| = 0; print "end\n"; print "", must immediately flush the buffered data, since $| has changed from 0 to 1. One thing that could help is if someone could take the time to write a test for this bug. Unfortunately I don't seem to be able to reproduce the problem, so I can't debug the problem. It could be a bug on the mod_deflate's behalf as well. Philippe, were you able to reproduce the problem with Bill's setup? I was writing a test, but couldn't get it to fail... may be because i was using 2.0.47. Bill, do you have the problem with the latest apache version? Also Bill, why do you have this setup: AddOutputFilterByType DEFLATE text/* SetOutputFilter DEFLATE why adding it twice? You need only the latter inside , or alternatively only the former outside if you want it to be set globally: http://httpd.apache.org/docs-2.0/mod/core.html#addoutputfilterbytype __ 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 - BUG ?] Issue handing Apache config. error messages
Right. Could you possibly clarify the difference between SetHandler perl-script and SetHandler modperl? I'm still not sure I've got the straight of it yet... Issac Stas Bekman wrote: > Sreeji K Das wrote: > [...] > You need to use 'SetHandler perl-script' for that, see: > http://perl.apache.org/docs/2.0/user/config/config.html#C_SetHandler_
[MP2 - BUG ?] Issue handing Apache config. error messages
Following demonstrates the problem: $ cat /tmp/test.conf @Include = "/tmp/test1.conf"; Listen 43499 $ cat /tmp/test1.conf $Port = 42480; $ httpd -X -f /tmp/test.conf Syntax error on line 7 of /tmp/test.conf: Use of uninitialized value in subroutine entry at /tmp/CVS/virgin/modperl-2.0/blib/lib/Apache2/Apache/PerlSection.pm line 171. - I've confirmed that ap_walk_config() in modperl_config_insert() indeed returns a valid error message and this gets propogated to post_config() in PerlSection.pm & a dir $errmsg happens. I guess this has something to do with the double eval() happening. ie. one for Include, and then recursively for Port. I'll debug it further; but it'd be nice if some1 already knows the issue and has a solution ! thx Sreeji Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://uk.messenger.yahoo.com/
RE: Possible bug using NTLMv2 across trusted domains.
Hi, 1 - You must be aware, by now, that your machine is infected. Please install and run a recented/updated antivirus. The fact that your question contained a virus is a good reason why nobody answered it. 2 - This list is for mod_perl questions; asking about a particular module is OT (Off-Topic) and that's another reason why nobody answered. 3 - Even if it was on topic, you're testing with *very* old service packs. If you, absolutely, must use an old service pack, then please tell us why; The question is, maybe it's not a bug on the NTLM2 module - but a bug on Windows NT itself, eventualy corrected in SP6a. This is the final reason why your question will remain... unanswered. So, please install both SP6a and the post-sp6a "security rollup package" on the Windows NT machines, and then contact the module author (or whatever procedures for bug reporting are in the module documentation). Regards, Paulo Meireles -Mensagem original- De: Kevin [mailto:[EMAIL PROTECTED] Enviada: segunda-feira, 7 de Julho de 2003 17:38 Para: undisclosed-recipients: Assunto: Possible bug using NTLMv2 across trusted domains. I believe I have found a problem with NTLMv2 authentication across trusted domains. the setup: DomainA (PDC-A and BDC-A both SP4) DomainB (PDC-B and BDC-B both SP4) Two-way trust exists between DomainA and DomainB client machine (Client1) tested with both SP4 & SP5 resides in DomainA When I add the value LMCompatibilityLevel in HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\LSA and set it at 3 (send NTLMv2 response only) everyth@
[MP2 BUG] PerlPassEnv issues
Looks like PerlSetEnv's are not propagated as
expected.
I've pasted my original mail to the list. However,
after going through the code, it looks like
scfg->PassEnv is not synced with Perl's %ENV
structure.
Following is a simpler example:
$ cat /tmp/test.conf
;
PerlPassEnv MY_TEST_VAR
print "MY_TEST_VAR is $ENV{MY_TEST_VAR}\n";
system("echo \"shell: MY_TEST_VAR = \$MY_TEST_VAR\"");
Listen 43499
$ httpd -X -f /m/aru/conf/test.conf
MY_TEST_VAR is
shell: MY_TEST_VAR = Hello there
MY_TEST_VAR is
shell: MY_TEST_VAR = Hello there
I think either modperl_cmd_pass_env() should sync the
vars. as and when it sees one (but this may not be
efficient). Or, modperl_cmd_perldo() should sync
(by calling modperl_env_table_populate() ?) before
doing the eval(). I tried doing this, but couldn't
figure out how to get a pTHX_ !
(The same problem would be applicable to PerlSetEnv as
well, I guess).
Any temporary hacks to fix this, so that I can
continue my testing ?
thx
Sreeji
---
Hi
It looks like when I @Include a file from a
section, the
sections in that file get processed first, though
there are other stuff
before the sections.
Following is an example (simplified from my real-life
config) :
$ cat /tmp/test.conf
@Include = "/tmp/testvar.conf";
Listen 43499
$ cat /tmp/testvar.conf
PerlPassEnv MY_TEST_VAR
print "MY_TEST_VAR = $ENV{MY_TEST_VAR}\n";
$ httpd -X -f /tmp/test.conf
[Sun Jul 06 06:15:09 2003] [warn] Syntax error at
/tmp/testvar.conf:5 Use
of uninitialized value in concatenation (.) or string
at (eval 3) line 1.
So when an Include is found, all perlsections in that
file are processed.
However, as in the above case, these sections
could be depending on
the directives defined previously in the file.
It works if I move the PerlPassEnv to test.conf, above
the section.
Any thoughts ?
thx
Sreeji
(this is 1.99_10-dev on Linux, with httpd-2.0.45)
Want to chat instantly with your online friends? Get the FREE Yahoo!
Messenger http://uk.messenger.yahoo.com/
Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)
On Thu, 2003-07-03 at 01:24, Bill Marrs wrote:
> This fixed the bug for me.
Great! Will commit it in the near future. (Can't seem to access the cvs
server right now, crappy internet cafe)
One thing that could help is if someone could take the time to write a
test for this bug.
Gozer out.
> At 10:48 AM 7/2/2003, you wrote:
> > #define mpxs_output_flush(r, rcfg) \
> > /* if ($|) */ \
> >-if (IoFLUSH(PL_defoutgv)) { \
> >+if (bytes > 0 && IoFLUSH(PL_defoutgv)) { \
> > MP_FAILURE_CROAK(modperl_wbucket_flush(rcfg->wbucket, TRUE)); \
> > }
>
>
signature.asc
Description: This is a digitally signed message part
Re: [mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)
This fixed the bug for me.
At 10:48 AM 7/2/2003, you wrote:
#define mpxs_output_flush(r, rcfg) \
/* if ($|) */ \
-if (IoFLUSH(PL_defoutgv)) { \
+if (bytes > 0 && IoFLUSH(PL_defoutgv)) { \
MP_FAILURE_CROAK(modperl_wbucket_flush(rcfg->wbucket, TRUE)); \
}
[mp2 Patch] BUG with mod_deflate and $|=1 (20014:Error string not specified)
Seems to be a problem with calling IoFLUSH() on an already flushed
handle.
This patch seems to fix it for me.
Index: xs/Apache/RequestIO/Apache__RequestIO.h
===
RCS file: /home/cvs/modperl-2.0/xs/Apache/RequestIO/Apache__RequestIO.h,v
retrieving revision 1.37
diff -u -I$Id -r1.37 Apache__RequestIO.h
--- xs/Apache/RequestIO/Apache__RequestIO.h 14 Mar 2003 05:33:19 - 1.37
+++ xs/Apache/RequestIO/Apache__RequestIO.h 2 Jul 2003 14:46:37 -
@@ -22,7 +22,7 @@
#define mpxs_output_flush(r, rcfg) \
/* if ($|) */ \
-if (IoFLUSH(PL_defoutgv)) { \
+if (bytes > 0 && IoFLUSH(PL_defoutgv)) { \
MP_FAILURE_CROAK(modperl_wbucket_flush(rcfg->wbucket, TRUE)); \
}
On Wed, 2003-07-02 at 22:18, Bill Marrs wrote:
> When I use Apache 2.0.46, mod_deflate with mod_perl-1.99_09 (or the latest
> mod_perl-2.0 CVS), perl buffering is off ($|=1), and my perl script prints
> nothing (e.g. 'print "";'), I get the following error:
>
> [Wed Jul 02 10:10:00 2003] [error] 19513: ModPerl::RegistryBB: 20014:Error
> string not specified yet at /var/www/perl/test.pl line 6.
>
> If I switch to running the script under mod_cgi or if I remove the "$|=1;"
> line, I do not get an error.
>
> Here is my script:
>
> #!/usr/bin/perl
> $|=1;
> print "Content-Type: text/html\n\n";
> print "hello world";
> # This line causes the error
> print "";
>
> httpd.conf snipit:
>
> Alias /perl/ /var/www/perl/
>
>AddOutputFilterByType DEFLATE text/*
>SetOutputFilter DEFLATE
>AllowOverride None
>SetHandler perl-script
>PerlHandlerModPerl::RegistryBB
>PerlSendHeader On
>Options+ExecCGI
>
>
> I've worked-around this problem by changing my print "" to print " ". It's
> not a major issue for me, I'm just letting you know. Let me know if you
> need any more info.
>
> -bill
>
>
signature.asc
Description: This is a digitally signed message part
[mp2] BUG with mod_deflate and $|=1 (20014:Error string not specified)
When I use Apache 2.0.46, mod_deflate with mod_perl-1.99_09 (or the latest mod_perl-2.0 CVS), perl buffering is off ($|=1), and my perl script prints nothing (e.g. 'print "";'), I get the following error: [Wed Jul 02 10:10:00 2003] [error] 19513: ModPerl::RegistryBB: 20014:Error string not specified yet at /var/www/perl/test.pl line 6. If I switch to running the script under mod_cgi or if I remove the "$|=1;" line, I do not get an error. Here is my script: #!/usr/bin/perl $|=1; print "Content-Type: text/html\n\n"; print "hello world"; # This line causes the error print ""; httpd.conf snipit: Alias /perl/ /var/www/perl/ AddOutputFilterByType DEFLATE text/* SetOutputFilter DEFLATE AllowOverride None SetHandler perl-script PerlHandlerModPerl::RegistryBB PerlSendHeader On Options+ExecCGI I've worked-around this problem by changing my print "" to print " ". It's not a major issue for me, I'm just letting you know. Let me know if you need any more info. -bill
[mp2] UN-bug!
Hi Stas and guys - As of Sat May 31 08:38:30 UTC 2003 1) I have the following installed and tested: Server Version: Apache/2.0.46 (Unix) mod_perl/1.99_10-dev (CVS) Perl/v5.8.0 mod_ssl/2.0.46 OpenSSL/0.9.7b 2) Everything is looking good! 3) GOOD JOB FOLKS... Aloha => Beau;
BUG [in docs] mailing list subscription does not actually indicatelist post address
http://perl.apache.org/maillist/email-etiquette.html > Posting to the list is just sending a message to the > address which you will be given after you subscribe. The above should either be updated, or the welcome message should be updated. I've just subscribed to the digest version, and the welcome message didn't actually indicate the list post address. Assuming the usual conventions apply, I assume I'm sending to the correct address. Someone new to mailing lists might not be able to guess correctly. -matt (who is soon unsubscribing. Thanks for your time :)
BUG [in docs] semicolon-separated param pairs fail w/ MSIE in metaredirect tags
Stas wrote: > Matthew, can you please repost it to the mod_perl list? > There are many more people who can followup on this. > Thanks. I won't be subscribed long enough to read any replies to this mesg, but am posting here at Stas' suggestion. Hopefully someone here will be able to update the docs if appropriate. Yesterday I was reading http://perl.apache.org/docs/tutorials/client/browserbugs/browserbugs.html and noticed: > either you should avoid using such keys > or you should separate parameter pairs > with ; instead of & This is fine advice. It's standards compliant and *should* work perfectly. In practice, it does work with one exception. MSIE (or at least certain recent versions of it) can fail to redirect properly if you use ; separators in a URL which is used in a meta redirect tag. Suppose the URL to which you're redirecting is supposed to contain a parameter "volt" with value "1" and another parameter "amp" with a value of "2". The URL could be either of these two if you're using CGI.pm http://example.com/?volt=1&=2 http://example.com/?volt=1;amp=2 Since the URL is appearing in HTML, then you have to HTML entity encode the URL, which means that the URL in your meta redirect tag needs to be either of these two http://example.com/?volt=1&=2 http://example.com/?volt=1;amp=2 Either of those *should* work in functional browsers. However, (at least certain versions of) MSIE will incorrectly read those two urls (if found in meta redirects) as http://example.com/?volt=1&=2 http://example.com/?volt=1 Note that the second URL lost everything after the semicolon. In versions of MSIE which are afflicted in this manner, you can only have semicolons in your URL if they are the terminal characters of HTML entity encoding sequences. This means that in your meta redirects you *must* use the encoded & character (& or a numeric encoding) to separate your parameter name/value pairs *unless* you can be certain that none of your users will be using one of the broken browsers. See also http://rt.cpan.org/NoAuth/Bug.html?id=2130 I thought this note might be appropriate to add to http://perl.apache.org/docs/tutorials/client/browserbugs/browserbugs.html -matt (who is now unsubscribing. Thanks for your time :)
Bug: system()-Call: CmdLine more than 128 Chars
Hi,
My Config:
- Windows 98 SE (+ all WinUpdate-Patches)
- Apache 2.0.44 (+ apr-Patch)
- ActivePerl 5.8.0 (ActivePerl-5.8.0.804-MSWin32-x86.msi)
- mod_perl 1.99_09-dev ("ppm install
http://theoryx5.uwinnipeg.ca/ppms/mod_perl.ppd";)
I have the following Problem:
When I call "system()" from a Perl-Script with a CommandLine
longer than (merged) about 128 Characters (not exact 128):
system('prog','1234567890123456789012345678901234567890
1234567890123456789012345678901234567890
1234567890123456789012345678901234567890
1234567890'); # In one line
-> then Perl does not execute the program, but the Apache-Console-Window
shows the DOS-Command-Prompt (as I started command.com),
and the Thread hangs, of course, and waits for input.
Microsoft(R) Windows 98
(C)Copyright Microsoft Corp 1981-1999.
C:\>
When I repeat this MaxThreads-times, Apache does not respond any more.
But:
- When I run the Perl-Script as CGI with Perl 5.8 it works fine.
- And also if I run ActivePerl-5.6.1.635 it works fine with mod_perl.
It seems to be a Bug in either mod_perl or Perl itself,
(Or a forgotton Workaround on a Windows-Bug *g*), i don't know.
Thanks
- Mark
Fwd: Re: [MP2] Apache::Reload date bug
--- Original Message --- From: "Stas Bekman" <[EMAIL PROTECTED]> To: Ron Savage <[EMAIL PROTECTED]> Cc: Sent: Sat, 01 Mar 2003 12:47:39 +1100 Subject: Re: [MP2] Apache::Reload date bug >Ron Savage wrote: >>On Tue, 25 Feb 2003 09:40:05 +1100, Stas Bekman wrote: >> >>Hi Stas >> >> >>>>Output when run as /perl/main.cgi. Only the first line is expected >>>>(by me.) Ie why does the text from OK down, appear? : >>>>-><8- >>>>This is a string >>>>OK >>>>The server encountered an internal error or misconfiguration and >>>>was >>>>unable to complete your request. >>>> >>>>Please contact the server administrator, [EMAIL PROTECTED] and >>>>inform >>>>them of the time the error occurred, and anything you might have >>>>done >>>>that may have caused the error. >>>> >>>>More information about this error may be available in the server >>>>error log. >>> >> >>Thanx. This particular problem has been fixed. > >cool. please followup on the list. So others know as well. Oops. -- Cheers Ron Savage, [EMAIL PROTECTED] on 02/03/2003 http://savage.net.au/index.html
Re: [MP2] Apache::Reload date bug
On Wed, 26 Feb 2003 22:30:51 -0600 (CST), Randy Kobes wrote: >On Thu, 27 Feb 2003, Ron Savage wrote: > >>On Wed, 26 Feb 2003 09:23:39 +1100, Stas Bekman wrote: HI Randy >The mod_perl 2 ppm package (for ActivePerl 8xx) at >http://theoryx5.uwinnipeg.ca/ppms/ is updated >periodically with a cvs build - as of tonight, it's >current. Thanx. Now my dual-booter at work is working, I hope to try this tomorrow. It's 8pm here now. -- Cheers Ron Savage, [EMAIL PROTECTED] on 27/02/2003 http://savage.net.au/index.html
Re: [MP2] Apache::Reload date bug
On Thu, 27 Feb 2003, Ron Savage wrote: > On Wed, 26 Feb 2003 09:23:39 +1100, Stas Bekman wrote: > > Hi Stas > > >Have you tried the current mod_perl cvs? > > No. Being usually a Windows (shudder) user, I wait for Randy to issue > a build. The mod_perl 2 ppm package (for ActivePerl 8xx) at http://theoryx5.uwinnipeg.ca/ppms/ is updated periodically with a cvs build - as of tonight, it's current. -- best regards, randy
Re: [MP2] Apache::Reload date bug
On Wed, 26 Feb 2003 09:23:39 +1100, Stas Bekman wrote: Hi Stas >Have you tried the current mod_perl cvs? No. Being usually a Windows (shudder) user, I wait for Randy to issue a build. Today I spent 4 hours failing to install Red Hat 6, Red Hat 8 and Mandrake 9 on a brand new Dell with a 82854G/GL video chip. I was aiming for a dual-boot system. Amazing :-(. -- Cheers Ron Savage, [EMAIL PROTECTED] on 27/02/2003 http://savage.net.au/index.html
Re: [MP2] Apache::Reload date bug
Ron Savage wrote: On Tue, 25 Feb 2003 09:40:05 +1100, Stas Bekman wrote: And what your error_log says? Nothing is output to the error_log. Have you tried the current mod_perl cvs? __ 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] Apache::Reload date bug
On Tue, 25 Feb 2003 09:40:05 +1100, Stas Bekman wrote: >And what your error_log says? Nothing is output to the error_log. -- Cheers Ron Savage, [EMAIL PROTECTED] on 25/02/2003 http://savage.net.au/index.html
Re: [MP2] Apache::Reload date bug
Ron Savage wrote:
On Wed, 19 Feb 2003 10:04:02 +1100, Stas Bekman wrote:
Ron Savage wrote:
On Tue, 18 Feb 2003 12:56:38 +1100, Stas Bekman wrote:
Hi Folks
In endeavouring to reproduce this problem, I've encountered another:
main.cgi:
-><8-
#!/usr/bin/perl
use strict;
use warnings;
use CGI;
use Dummy;
# --
my($title) = 'Test';
my($q) = CGI -> new();
my($s) = Dummy -> string();
print $q -> header({type => 'text/html;charset=ISO-8859-1'}),
$q -> start_html({title => $title}),
$q -> h1({align => 'center'}, $s),
$q -> end_html();
-><8-
Dummy.pm (in /perl/site/lib/):
-><8-
package Dummy;
sub string{'This is a string'}
1;
-><8-
Output when run as /perl/main.cgi. Only the first line is expected
(by me.) Ie why does the text from OK down, appear? :
-><8-
This is a string
OK
The server encountered an internal error or misconfiguration and was
unable to complete your request.
Please contact the server administrator, [EMAIL PROTECTED] and inform
them of the time the error occurred, and anything you might have done
that may have caused the error.
More information about this error may be available in the server
error log.
And what your error_log says?
OK is part of the error message. I think I've fixed that in the cvs version.
See if you get any better with it.
__
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] Apache::Reload date bug
On Wed, 19 Feb 2003 10:04:02 +1100, Stas Bekman wrote:
>Ron Savage wrote:
>>On Tue, 18 Feb 2003 12:56:38 +1100, Stas Bekman wrote:
Hi Folks
In endeavouring to reproduce this problem, I've encountered another:
main.cgi:
-><8-
#!/usr/bin/perl
use strict;
use warnings;
use CGI;
use Dummy;
# --
my($title) = 'Test';
my($q) = CGI -> new();
my($s) = Dummy -> string();
print $q -> header({type => 'text/html;charset=ISO-8859-1'}),
$q -> start_html({title => $title}),
$q -> h1({align => 'center'}, $s),
$q -> end_html();
-><8-
Dummy.pm (in /perl/site/lib/):
-><8-
package Dummy;
sub string{'This is a string'}
1;
-><8-
Output when run as /perl/main.cgi. Only the first line is expected
(by me.) Ie why does the text from OK down, appear? :
-><8-
This is a string
OK
The server encountered an internal error or misconfiguration and was
unable to complete your request.
Please contact the server administrator, [EMAIL PROTECTED] and inform
them of the time the error occurred, and anything you might have done
that may have caused the error.
More information about this error may be available in the server
error log.
--
--
Apache/2.0.43 Server at 127.0.0.1 Port 80
-><8-
The part of httpd.conf controlling /perl/. Note Dummy is not included
here, but the original module, which revealed the original bug, is:
><8
PerlModule Apache::Reload
PerlInitHandler Apache::Reload
PerlSetVar ReloadAll Off
PerlSetVar ReloadModules "CGI::Explorer DBIx::AdminEngine Monash::*
Sweep::*"
#PerlSwitches -Mblib=C:\Apache2
PerlRequire "C:/Apache2/conf/startup.pl"
Alias /perl/ "C:/Apache2/perl/
SetHandler perl-script
PerlResponseHandler ModPerl::Registry
Options +ExecCGI
PerlOptions +ParseHeaders
Order deny,allow
Deny from all
Allow from 127.0.0.1
><8
I'll keep working on the original problem.
--
Cheers
Ron Savage, [EMAIL PROTECTED] on 24/02/2003
http://savage.net.au/index.html
Re: [MP2] Apache::Reload date bug
Randy Kobes wrote:
On Wed, 19 Feb 2003, Stas Bekman wrote:
Ron Savage wrote:
On Tue, 18 Feb 2003 12:56:38 +1100, Stas Bekman wrote:
perl -le 'warn("foo\n")'
You got the quotes wrong for MS Windows, so I ran it twice:
C:\Backup>perl -le "warn(qq|foo\n|)"
foo
C:\Backup>perl -le 'warn("foo\n")'
well, you've got the idea, right.
Perhaps someone on win32 can try to debug the behavior that you
saw. I can't reproduce it on my linux box.
With my ActivePerl 8xx compatible perl-5.8, sticking in a
warn("foo\n");
inside a simple handler that uses Apache::Reload
just output "foo" in the error log, with no timestamp
nor client reported, as expected. I'm wondering though
if this is coming from one of the custom modules
used - in the log
===
[Sun Feb 16 23:49:41 2003] -e: Apache::Reload: Can't locate
C:/Perl/site/lib//CGI/Explorer.pm
===
the message from Apache::Reload:
warn("Apache::Reload: Can't locate $file\n"), next
unless defined $mtime amd $mtime;
has a '-e:' in front, suggesting perhaps that another
module is contributing to this entry. Can you make up
a stripped-down version that exhibits this behaviour?
I thought of that too, but wasn't sure if this is something special to win32.
Could it be that the logs get interleaved?
__
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] Apache::Reload date bug
On Wed, 19 Feb 2003, Stas Bekman wrote:
> Ron Savage wrote:
> > On Tue, 18 Feb 2003 12:56:38 +1100, Stas Bekman wrote:
> >
> >>perl -le 'warn("foo\n")'
> >
> > You got the quotes wrong for MS Windows, so I ran it twice:
> >
> > C:\Backup>perl -le "warn(qq|foo\n|)"
> > foo
> >
> > C:\Backup>perl -le 'warn("foo\n")'
>
> well, you've got the idea, right.
>
> Perhaps someone on win32 can try to debug the behavior that you
> saw. I can't reproduce it on my linux box.
With my ActivePerl 8xx compatible perl-5.8, sticking in a
warn("foo\n");
inside a simple handler that uses Apache::Reload
just output "foo" in the error log, with no timestamp
nor client reported, as expected. I'm wondering though
if this is coming from one of the custom modules
used - in the log
===
[Sun Feb 16 23:49:41 2003] -e: Apache::Reload: Can't locate
C:/Perl/site/lib//CGI/Explorer.pm
===
the message from Apache::Reload:
warn("Apache::Reload: Can't locate $file\n"), next
unless defined $mtime amd $mtime;
has a '-e:' in front, suggesting perhaps that another
module is contributing to this entry. Can you make up
a stripped-down version that exhibits this behaviour?
--
best regards,
randy
Re: [MP2] Apache::Reload date bug
Ron Savage wrote:
On Tue, 18 Feb 2003 12:56:38 +1100, Stas Bekman wrote:
perl -le 'warn("foo\n")'
You got the quotes wrong for MS Windows, so I ran it twice:
C:\Backup>perl -le "warn(qq|foo\n|)"
foo
C:\Backup>perl -le 'warn("foo\n")'
well, you've got the idea, right.
Perhaps someone on win32 can try to debug the behavior that you saw. I can't
reproduce it on my linux box.
__
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] Apache::Reload date bug
On Tue, 18 Feb 2003 12:56:38 +1100, Stas Bekman wrote:
>perl -le 'warn("foo\n")'
You got the quotes wrong for MS Windows, so I ran it twice:
C:\Backup>perl -le "warn(qq|foo\n|)"
foo
C:\Backup>perl -le 'warn("foo\n")'
C:\Backup>
--
Cheers
Ron Savage, [EMAIL PROTECTED] on 19/02/2003
http://savage.net.au/index.html
Re: [MP2] Apache::Reload date bug
Ron Savage wrote:
Folks
I don't know if this an Apache problem, or a mod_perl problem.
Apache::Reload outputs a UTC date rather than a local date, when it
encounters an error. Here's an excerpt from my log.
Notice how the dates go Sun, Mon, ..., Sun.
[Sun Feb 16 18:31:25 2003] [error] [client 127.0.0.1] Execution of
C:/Apache2/cgi-bin/test/test-path-info.cgi aborted due to compilation
errors., referer: http://127.0.0.1/cgi-bin/test/test-path-info.cgi
[Mon Feb 17 10:44:04 2003] [error] [client 127.0.0.1] Premature end
of script headers: menu-process-module.cgi, referer:
http://127.0.0.1/cgi-bin/menu-process-module.cgi
[Mon Feb 17 10:44:04 2003] [error] [client 127.0.0.1] Can't locate
Module/MakeDist.pm in @INC (@INC contains: C:/Perl/lib
C:/Perl/site/lib .) at C:/Apache2/cgi-bin/menu-process-module.cgi
line 15., referer: http://127.0.0.1/cgi-bin/menu-process-module.cgi
[Mon Feb 17 10:44:04 2003] [error] [client 127.0.0.1] BEGIN
failed--compilation aborted at
C:/Apache2/cgi-bin/menu-process-module.cgi line 15., referer:
http://127.0.0.1/cgi-bin/menu-process-module.cgi
[Sun Feb 16 23:49:41 2003] -e: Apache::Reload: Can't locate
C:/Perl/site/lib//CGI/Explorer.pm
I wonder why do you get the timestamp in first place, Apache::Reload does:
warn("Apache::Reload: Can't locate $file\n"), next
unless defined $mtime and $mtime;
which is a pure perl call. Or does perl on windows adds a timestamp when
loggin warnings? In any case, I doubt this has anything to do with mod_perl.
The [client 127.0.0.1] errors come from Apache, Apache::Reload warnings are
coming from perl. check what do you get when you run:
perl -le 'warn("foo\n")'
__
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
[MP2] Apache::Reload date bug
Folks I don't know if this an Apache problem, or a mod_perl problem. Apache::Reload outputs a UTC date rather than a local date, when it encounters an error. Here's an excerpt from my log. Notice how the dates go Sun, Mon, ..., Sun. [Sun Feb 16 18:31:25 2003] [error] [client 127.0.0.1] Execution of C:/Apache2/cgi-bin/test/test-path-info.cgi aborted due to compilation errors., referer: http://127.0.0.1/cgi-bin/test/test-path-info.cgi [Mon Feb 17 10:44:04 2003] [error] [client 127.0.0.1] Premature end of script headers: menu-process-module.cgi, referer: http://127.0.0.1/cgi-bin/menu-process-module.cgi [Mon Feb 17 10:44:04 2003] [error] [client 127.0.0.1] Can't locate Module/MakeDist.pm in @INC (@INC contains: C:/Perl/lib C:/Perl/site/lib .) at C:/Apache2/cgi-bin/menu-process-module.cgi line 15., referer: http://127.0.0.1/cgi-bin/menu-process-module.cgi [Mon Feb 17 10:44:04 2003] [error] [client 127.0.0.1] BEGIN failed--compilation aborted at C:/Apache2/cgi-bin/menu-process-module.cgi line 15., referer: http://127.0.0.1/cgi-bin/menu-process-module.cgi [Sun Feb 16 23:49:41 2003] -e: Apache::Reload: Can't locate C:/Perl/site/lib//CGI/Explorer.pm -- Cheers Ron Savage, [EMAIL PROTECTED] on 17/02/2003 http://savage.net.au/index.html
[mp2] Bug : Weird failures
-BEGIN PGP SIGNED MESSAGE- Hash: MD5 Just for the record, in case it helps someone, I'm getting weird failures, unpredictably -- there's not one thing that seems to set it off: sometimes they happen, sometimes they don't. [Thu Feb 13 10:12:28 2003] [notice] Parent: child process exited with status 3221225477 -- Restarting. Apache server version Apache/2.0.43 (Win32) mod_perl/1.99_08-dev Perl/v5.8.0, built on Apache::Constants::SERVER_BUILT I'm also using Apache::Reload, SetHandler perl-script, and PerlResponseHandler. The sever restarts beautifully. No reply necessary (unless you'd like to tell me where Apache::Constants::SERVER_BUILT went :) lee $$=qw$808273788400074285838400657879847269820080698276007265677569820727$; $$=~s$(\d\d)$\$_.=chr(\$1+32)$ge;eval; -BEGIN PGP SIGNATURE- Version: 2.6 iQCVAwUAPktns6drfekeF/QBAQFwDgQAmdoXKhQimYgr5xiUYvTtcQsv/1izOjbJ 5gKmyHho5LnpPTD799bbDv3TPBrAZIgrGUA+4p+HATf5Wmt4GJshXlFu5ZFk0CDP g/ZBVtEcj3jl0JLlRdmGRzGhP/+LHhFGCl5iOjgmZ92njZuJa9Z3bYrLBdwp4RBc O6p/3XgmQLg= =nv+U -END PGP SIGNATURE-
Re: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
Geoffrey Young wrote: OK, so we are not done with it. The first thing I'd like to see is to have Apache::Registry and Apache::PerlRun agree on how they handle return codes, because they aren't the same. Once this happens, the Cooker will do the same. As you have mentioned we have a problem with relying on return status. Because if the script doesn't use the mod_perl API, it normally may return absolutely anything, which may mess things up. So the safest approach, is to run the script, ignore its return value (not status!) and return OK or SERVER_ERROR based on whether the execution was error-free or not. Plus add the hack of returning of the new status if it was changed by the script. That's the approach that is taken by Apache::Registry and it seems that most people are happy with it. PerlRun does return the execution status, but when I first made the Cooker use this approach we immediately received a bug report, where the script wasn't doing the right thing. I can't remember whether you modeled Cooker after PerlRun or RegistryNG. the current logic in RegistryNG represents a recent change and is my fault http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=101240123609773&w=2 basically, I was trying to fix pretty much what we're talking about but might have gotten it wrong. we probably ought to just follow the 1.0 Registry formula, since I can't remember anybody complaining about it in recent memory. that is, if we're going to have one version - see my other email for thoughts on having two versions of Registry :) I don't see what's wrong with your change, it brings things to be more consistent with Registry.pm. I've modeled the RegistryCooker after PerlRun.pm/RegistryNG.pm, but referring to Registry.pm when unsure. In any case, let's leave 1.0 alone (those who need it changed, can subclass RegistryNG) and work out a good 2.0. Re: ModPerl::RegistryCooker and its subclasses, you have to come forward and send tests that don't work as expected and we will act accordingly. My goal is to have an exhaustive test suite for registry scripts, because I'm sick of running my in-head built-in mod_perl ;) That includes lots of edge cases, for various error cases and such. Currently we have 34 tests, but more are needed. 206ok 404ok 500ok basic..ok closureok perlrun_requireok redirect...ok special_blocks.ok All tests successful. Files=8, Tests=34, 11 wallclock secs ( 6.80 cusr + 0.80 csys = 7.60 CPU) __ 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: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
OK, so we are not done with it. The first thing I'd like to see is to have Apache::Registry and Apache::PerlRun agree on how they handle return codes, because they aren't the same. Once this happens, the Cooker will do the same. As you have mentioned we have a problem with relying on return status. Because if the script doesn't use the mod_perl API, it normally may return absolutely anything, which may mess things up. So the safest approach, is to run the script, ignore its return value (not status!) and return OK or SERVER_ERROR based on whether the execution was error-free or not. Plus add the hack of returning of the new status if it was changed by the script. That's the approach that is taken by Apache::Registry and it seems that most people are happy with it. PerlRun does return the execution status, but when I first made the Cooker use this approach we immediately received a bug report, where the script wasn't doing the right thing. I can't remember whether you modeled Cooker after PerlRun or RegistryNG. the current logic in RegistryNG represents a recent change and is my fault http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=101240123609773&w=2 basically, I was trying to fix pretty much what we're talking about but might have gotten it wrong. we probably ought to just follow the 1.0 Registry formula, since I can't remember anybody complaining about it in recent memory. that is, if we're going to have one version - see my other email for thoughts on having two versions of Registry :) --Geoff
Re: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
The only thing that puzzles me about this thread is that it seems to be leaning towards the position that says; If the developer just does straight out weird stuff and messes with $r->status in a cgi-script and expects it to work with Apache::Registry (which as far as I understand is a cgi emulation layer), we will accommodate them. However, if the s/he just expects Apache::Registry to behave like it mod_cgi (except faster, more brilliant, etc :)) then they will be disappointed. I am probably just fixated over my current work and can't see the proverbial forest. Can somebody explain this for me? well, Apache::Registry started out as a mod_cgi emulation layer, trying to speed up legacy mod_cgi scripts without alteration. personally, I think that concept is flawed because we all know that many legacy CGI scripts are poorly written, so you need take special measure to not fall into the numerous documented Registry traps. not to mention that Registry doesn't handle HEAD requests properly (in 1.0), if you read POST data elsewhere you're SOL in your CGI script, etc. but, ok, say you have your CGI emulation layer - that's one facet of Registry. however, Registry also acts as a dispatch mechansim for people wanting to use the mod_perl API without writing separate handlers for each bit of functionality - since you get $r passed in automatically, or can retrieve it via Apache->request on your own, you are fully free to use Registry this way and many people do. fiddling with $r->status is _only_ possible when Registry is used in this way - there is no mod_cgi equivalent way to set that part of the request record (that I know about, anyway :) for people who want to use the mod_perl API to, say, return REDIRECT, there needs to be some mechanism to allow them to do so, and the $r->status hack has traditionally served this purpose. (one of) my points before was that with 2.0 and the Cooker idea, we really can (and ought to) have two versions of Registry to accomodate these two needs - people who just want faster mod_cgi (and Registry returns OK or SERVER_ERROR) and people who want the mod_perl API (and Registry returns the script return code). separating out the two classes of users will probably make the Registry logic much easier and cleaner. just my $0.02. --Geoff
Re: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
David Dick wrote: [...] The only thing that messed me up was when running a script with mod_cgi, you can return your own status codes and apache will happily go along with it. However, when you run the same script under mod_perl's Apache::Registry, you suddenly get Apache::Registry second guessing the script and adding to the script, something that for (especially) USE_LOCAL_COPY and PARTIAL_CONTENT responses is just wrong. I've just ended up writing my own version of Apache::Registry that always returns OK, which works for my purposes and therefore I'm content. The only thing that puzzles me about this thread is that it seems to be leaning towards the position that says; If the developer just does straight out weird stuff and messes with $r->status in a cgi-script and expects it to work with Apache::Registry (which as far as I understand is a cgi emulation layer), we will accommodate them. However, if the s/he just expects Apache::Registry to behave like it mod_cgi (except faster, more brilliant, etc :)) then they will be disappointed. I am probably just fixated over my current work and can't see the proverbial forest. Can somebody explain this for me? Personally I don't see how is it possible to accomodate everybody in the same handler. Because the requirements are conficting and second guessing is working in 99% but breaks for 1%, causing torn out hairs. Perhaps having two different sub-classes which do things differently is the right way to go. The default should follow the course of the least surprise and accomplish what it was designed for in first place: emulate mod_cgi, while giving the speed benefits. The other sub-class should pitch towards developers that use registry, for scripts which are expected to behave differently from mod_cgi. Looks like that's what we have under mod_perl 1.0. Apache::Registry and Apache::PerlRun/RegistryNG behave differently and one should choose between the two according to their needs. Even though the overall implementation is different for a different reason (make a sub-classable registry). __ 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: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
Stas Bekman wrote: Geoffrey Young wrote: The logic here is simpler: 1. store the new status code (just in case the script has changed it) 2. reset the status code to the one before the script execution 3. if the script has attempted to change the status by itself and the execution status is Apache::OK return that new status. Otherwise return the execution status (which will be either Apache::OK or Apache::SERVER_ERROR) this is different that how Apache::Registry in 1.0 handles it, specifically under circumstances like redirects, where people typically do $r->headers_out(Location => '/foo'); $r->status(REDIRECT); return REDIRECT; what you're saying now is that the status is only propagated if you return OK. (at least that's what I _think_ you're saying - I'm still trying to get back after a week off :) the logic should probably be something like respect the execution status if it is OK or it matches the new status, making $r->status(REDIRECT); return OK; and $r->status(REDIRECT); return REDIRECT; both valid ways to effectively redirect the request from Registry. the $r->status() bit was always a hack - nobody is supposed to fiddle with $r->status, which is why mod_perl saves and restores it. we could do with a better way that saved us from all this logic for people who want to use Registry with the mod_perl API. perhaps a version of the Cooker that simply respected (and expected) the script to return a meaningful status code. thus, the script would return SERVER_ERROR if $@ is true, and the return status of the subroutine otherwise. of course, we can't do this in CGI-portable mode, but for folks that want to use Registry as a dispatch mechanism, this is really the preferred way. OK, so we are not done with it. The first thing I'd like to see is to have Apache::Registry and Apache::PerlRun agree on how they handle return codes, because they aren't the same. Once this happens, the Cooker will do the same. As you have mentioned we have a problem with relying on return status. Because if the script doesn't use the mod_perl API, it normally may return absolutely anything, which may mess things up. So the safest approach, is to run the script, ignore its return value (not status!) and return OK or SERVER_ERROR based on whether the execution was error-free or not. Plus add the hack of returning of the new status if it was changed by the script. That's the approach that is taken by Apache::Registry and it seems that most people are happy with it. PerlRun does return the execution status, but when I first made the Cooker use this approach we immediately received a bug report, where the script wasn't doing the right thing. The only thing that messed me up was when running a script with mod_cgi, you can return your own status codes and apache will happily go along with it. However, when you run the same script under mod_perl's Apache::Registry, you suddenly get Apache::Registry second guessing the script and adding to the script, something that for (especially) USE_LOCAL_COPY and PARTIAL_CONTENT responses is just wrong. I've just ended up writing my own version of Apache::Registry that always returns OK, which works for my purposes and therefore I'm content. The only thing that puzzles me about this thread is that it seems to be leaning towards the position that says; If the developer just does straight out weird stuff and messes with $r->status in a cgi-script and expects it to work with Apache::Registry (which as far as I understand is a cgi emulation layer), we will accommodate them. However, if the s/he just expects Apache::Registry to behave like it mod_cgi (except faster, more brilliant, etc :)) then they will be disappointed. I am probably just fixated over my current work and can't see the proverbial forest. Can somebody explain this for me?
Re: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
Geoffrey Young wrote: The logic here is simpler: 1. store the new status code (just in case the script has changed it) 2. reset the status code to the one before the script execution 3. if the script has attempted to change the status by itself and the execution status is Apache::OK return that new status. Otherwise return the execution status (which will be either Apache::OK or Apache::SERVER_ERROR) this is different that how Apache::Registry in 1.0 handles it, specifically under circumstances like redirects, where people typically do $r->headers_out(Location => '/foo'); $r->status(REDIRECT); return REDIRECT; what you're saying now is that the status is only propagated if you return OK. (at least that's what I _think_ you're saying - I'm still trying to get back after a week off :) the logic should probably be something like respect the execution status if it is OK or it matches the new status, making $r->status(REDIRECT); return OK; and $r->status(REDIRECT); return REDIRECT; both valid ways to effectively redirect the request from Registry. the $r->status() bit was always a hack - nobody is supposed to fiddle with $r->status, which is why mod_perl saves and restores it. we could do with a better way that saved us from all this logic for people who want to use Registry with the mod_perl API. perhaps a version of the Cooker that simply respected (and expected) the script to return a meaningful status code. thus, the script would return SERVER_ERROR if $@ is true, and the return status of the subroutine otherwise. of course, we can't do this in CGI-portable mode, but for folks that want to use Registry as a dispatch mechanism, this is really the preferred way. OK, so we are not done with it. The first thing I'd like to see is to have Apache::Registry and Apache::PerlRun agree on how they handle return codes, because they aren't the same. Once this happens, the Cooker will do the same. As you have mentioned we have a problem with relying on return status. Because if the script doesn't use the mod_perl API, it normally may return absolutely anything, which may mess things up. So the safest approach, is to run the script, ignore its return value (not status!) and return OK or SERVER_ERROR based on whether the execution was error-free or not. Plus add the hack of returning of the new status if it was changed by the script. That's the approach that is taken by Apache::Registry and it seems that most people are happy with it. PerlRun does return the execution status, but when I first made the Cooker use this approach we immediately received a bug report, where the script wasn't doing the right thing. __ 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: Registry return codes handling (was Re: Possible bug with a 206Partial Response)
The logic here is simpler: 1. store the new status code (just in case the script has changed it) 2. reset the status code to the one before the script execution 3. if the script has attempted to change the status by itself and the execution status is Apache::OK return that new status. Otherwise return the execution status (which will be either Apache::OK or Apache::SERVER_ERROR) this is different that how Apache::Registry in 1.0 handles it, specifically under circumstances like redirects, where people typically do $r->headers_out(Location => '/foo'); $r->status(REDIRECT); return REDIRECT; what you're saying now is that the status is only propagated if you return OK. (at least that's what I _think_ you're saying - I'm still trying to get back after a week off :) the logic should probably be something like respect the execution status if it is OK or it matches the new status, making $r->status(REDIRECT); return OK; and $r->status(REDIRECT); return REDIRECT; both valid ways to effectively redirect the request from Registry. the $r->status() bit was always a hack - nobody is supposed to fiddle with $r->status, which is why mod_perl saves and restores it. we could do with a better way that saved us from all this logic for people who want to use Registry with the mod_perl API. perhaps a version of the Cooker that simply respected (and expected) the script to return a meaningful status code. thus, the script would return SERVER_ERROR if $@ is true, and the return status of the subroutine otherwise. of course, we can't do this in CGI-portable mode, but for folks that want to use Registry as a dispatch mechanism, this is really the preferred way. --Geoff
Registry return codes handling (was Re: Possible bug with a 206 PartialResponse)
I did some more tweaking to ModPerl::RegistryCooker. I think my previous
implementation would have problems when the script has changed the status and
then failed (the failure would be ignored then). Please verify that this is
still good (the test suite passes, but it's not exhaustive).
# handlers shouldn't set $r->status but return it, so we reset the
# status after running it
my $old_status = $self->[REQ]->status;
my $rc = $self->run;
my $new_status = $self->[REQ]->status($old_status);
return ($old_status != $new_status && $rc == Apache::OK)
? $new_status
: $rc;
The logic here is simpler:
1. store the new status code (just in case the script has changed it)
2. reset the status code to the one before the script execution
3. if the script has attempted to change the status by itself and the
execution status is Apache::OK return that new status. Otherwise return the
execution status (which will be either Apache::OK or Apache::SERVER_ERROR)
So if that's valid, here are the suggested patches to bring all 3
implementations in sync (David, please check that both Registry and PerlRun
work for you):
Index: lib/Apache/Registry.pm
===
RCS file: /home/cvs/modperl/lib/Apache/Registry.pm,v
retrieving revision 1.34
diff -u -r1.34 Registry.pm
--- lib/Apache/Registry.pm 23 May 2002 04:21:07 - 1.34
+++ lib/Apache/Registry.pm 5 Feb 2003 06:14:00 -
@@ -169,7 +169,8 @@
# return REDIRECT;
# }
# }
- return $r->status($old_status);
+my $new_status = $r->status($old_status);
+return $old_status != $new_status ? $new_status : OK;
} else {
xlog_error($r, "$filename not found or unable to stat");
return NOT_FOUND unless $Debug && $Debug & 2;
Index: lib/Apache/RegistryNG.pm
===
RCS file: /home/cvs/modperl/lib/Apache/RegistryNG.pm,v
retrieving revision 1.8
diff -u -r1.8 RegistryNG.pm
--- lib/Apache/RegistryNG.pm 24 Mar 2002 22:06:39 - 1.8
+++ lib/Apache/RegistryNG.pm 5 Feb 2003 06:14:00 -
@@ -56,7 +56,7 @@
my $pr_status = $pr->status;
$r->status($old_status);
-return ($rc != OK) ? $rc : $pr_status;
+return ($rc == OK && $old_status != $new_status) ? $pr_status : $rc;
}
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: Possible bug with a 206 Partial Response
David Dick wrote: If I'm correct both Apache::PerlRun and Apache::Registry will have problems in certain situations if we agree that ModPerl::Registry has the correct logic for handling the execution status. If you can tell otherwise please give me a test script that doesn't work under ModPerl::Registry. But in your particular example, Dick, if you configure the I'm presuming that you simply mixed up which is my first name and surname? :) Usually dave is fine. :) Oops, sorry Dave ;) script to run under Apache::RegistryNG, does it work? No. So that confirms my suspicion that the problem in 1.0 implementation is that it unconditionally resets the status. If not, that's where the difference between 1.0 and 2.0 lays: ModPerl::Registry doesn't reset status if it wasn't changed by the script. well the ModPerl::Registry behaviour certainly suits my program. :) Good, though I'm not sure how to proceed from here. 1.0's registry doesn't have a test suite and I'm afraid to break other people's code on the next release. So perhaps someone will take a good look at it, before we move on with this change. In any case, you can subclass Apache::RegistryNG and override the handler() method to get things working for you now. or give a try to mp2.0. __ 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: Possible bug with a 206 Partial Response
If I'm correct both Apache::PerlRun and Apache::Registry will have problems in certain situations if we agree that ModPerl::Registry has the correct logic for handling the execution status. If you can tell otherwise please give me a test script that doesn't work under ModPerl::Registry. But in your particular example, Dick, if you configure the I'm presuming that you simply mixed up which is my first name and surname? :) Usually dave is fine. :) script to run under Apache::RegistryNG, does it work? No. If not, that's where the difference between 1.0 and 2.0 lays: ModPerl::Registry doesn't reset status if it wasn't changed by the script. well the ModPerl::Registry behaviour certainly suits my program. :) Uru -dave
Re: Possible bug with a 206 Partial Response
David Dick wrote:
alrightly, back again. The problem is that Apache::Registry will return
a 206, which will trigger the error message. In case there is anyone
out there as daft as me :), the crude delegation-type module below can
solve this problem. Maniacs who see a need to return 204's, etc can
probably extend this to a more general solution. :)
package MyPrefix::Apache::Registry;
use strict;
BEGIN {
use Apache::Registry();
use Apache::Constants qw(:common);
use constant PARTIAL_CONTENT => 206;
}
sub handler {
my ($return) = Apache::Registry::handler(@_);
if ($return == PARTIAL_CONTENT) {
return OK;
} else {
return ($return);
}
}
END { }
1;
When I've tried to run your test script under ModPerl::Registry
(mp2.0) I was surprised to learn that it worked just fine. So far I
was fixing the porting bugs ;) I've added your test script to the
ModPerl::Registry test suite.
We better fix it in the 1.0 core. But before that we need to be clear of how
the return codes should be handled, because the currect three implementations
all diverge when it comes to handling the return codes/execution status.
In order to simplify the logic, assuming that the script was
successfully executed and inlining some code, the 3 different registry
implementations resemble the following:
Apache::Registry does:
my $old_status = $r->status;
eval { &{$cv}($r, @_) };
return $r->status($old_status);
Apache::PerlRun/RegistryNG do:
my $old_status = $r->status;
eval { &{$cv}($r, @_) };
$r->status($old_status);
return OK;
ModPerl::RegistryCooker does:
# handlers shouldn't set $r->status but return it
my $old_status = $self->[REQ]->status;
eval { &{$cv}($r, @_) };
my $new_status = $self->[REQ]->status;
# only if the script has changed the status, reset to the old
# status and return the new status
return $old_status != $new_status
? $self->[REQ]->status($old_status)
: OK;
If I'm correct both Apache::PerlRun and Apache::Registry will have
problems in certain situations if we agree that ModPerl::Registry has
the correct logic for handling the execution status. If you can tell
otherwise please give me a test script that doesn't work under
ModPerl::Registry.
But in your particular example, Dick, if you configure the
script to run under Apache::RegistryNG, does it work? If not, that's where the
difference between 1.0 and 2.0 lays: ModPerl::Registry doesn't reset status if
it wasn't changed by the script.
__
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: Possible bug with a 206 Partial Response
alrightly, back again. The problem is that Apache::Registry will return
a 206, which will trigger the error message. In case there is anyone
out there as daft as me :), the crude delegation-type module below can
solve this problem. Maniacs who see a need to return 204's, etc can
probably extend this to a more general solution. :)
package MyPrefix::Apache::Registry;
use strict;
BEGIN {
use Apache::Registry();
use Apache::Constants qw(:common);
use constant PARTIAL_CONTENT => 206;
}
sub handler {
my ($return) = Apache::Registry::handler(@_);
if ($return == PARTIAL_CONTENT) {
return OK;
} else {
return ($return);
}
}
END { }
1;
Uru
-Dave
Ged Haywood wrote:
Hi again,
On Mon, 3 Feb 2003, David Dick wrote:
not even getting a broken connection. So somehow mod_perl doesn't
_really_ think it's an error.
Check out DEBUGGING in 'perldoc Apache::Registry'.
Apache::Registry won't always return what you'd think it should.
This has snookered more than one in the past...
73,
Ged.
Re: Possible bug with a 206 Partial Response
Hi again, On Mon, 3 Feb 2003, David Dick wrote: > not even getting a broken connection. So somehow mod_perl doesn't > _really_ think it's an error. Check out DEBUGGING in 'perldoc Apache::Registry'. Apache::Registry won't always return what you'd think it should. This has snookered more than one in the past... 73, Ged.
Re: Possible bug with a 206 Partial Response
not even getting a broken connection. So somehow mod_perl doesn't _really_ think it's an error. Ged Haywood wrote: Hi there, On Sun, 2 Feb 2003, David Dick wrote: Forgot to mention that the error log is completely empty. :) Are you getting core dumps? 73, Ged.
Re: Possible bug with a 206 Partial Response
Hi there, On Sun, 2 Feb 2003, David Dick wrote: > Forgot to mention that the error log is completely empty. :) Are you getting core dumps? 73, Ged.
Re: Possible bug with a 206 Partial Response
Good Point. Forgot to mention that the error log is completely empty. :) Ged Haywood wrote: Hi there, On Sun, 2 Feb 2003, David Dick wrote: Got a bit of a weird set of behaviour with a mod_perl Apache::Registry type script. [snip] More information about this error may be available in the server error log. [snip] Anyone got any ideas? What does it say in the error_log? 73, Ged.
Re: Possible bug with a 206 Partial Response
Hi there, On Sun, 2 Feb 2003, David Dick wrote: > Got a bit of a weird set of behaviour with a mod_perl Apache::Registry > type script. [snip] > More information about this error may be available > in the server error log. [snip] > Anyone got any ideas? What does it say in the error_log? 73, Ged.
Possible bug with a 206 Partial Response
G'day all,
Got a bit of a weird set of behaviour with a mod_perl Apache::Registry
type script.
HISTORY:
I've been using MD5 digests of the html sent from my scripts as ETags,
hence saving an important bit of bandwidth. Got a little bit carried
away with the success of this project and attempted to handle range
requests as well. Worked fine when running as a CGI script, but blew a
fuse when running as an Apache::Registry script. Stripped the script
down to the basics and the error continued.
I have a script called test.pl which has the following content.
#! /usr/bin/perl -wT
MAIN: {
print <<_OUT_;
Status: 206 Partial Content
Content-Type: text/html; charset=UTF-8
Content-Length: 11
Content-Range: bytes 0-10/1336
Date: Fri, 31 Jan 2003 09:39:01 GMT
ETag: ""
_OUT_
print '
}
When the script is run, the following output appears.
[dave@localhost]$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET /test.pl HTTP/1.1
Host: localhost
HTTP/1.1 206 Partial Content
Date: Sat, 01 Feb 2003 22:12:47 GMT
Server: Apache
Content-Range: bytes 0-10/1336
ETag: ""
Content-Length: 11
Content-Type: text/html; charset=UTF-8
206 Partial Content
Partial Content
The server encountered an internal error or
misconfiguration and was unable to complete
your request.
Please contact the server administrator,
[EMAIL PROTECTED] and inform them of the time the error occurred,
and anything you might have done that may have
caused the error.
More information about this error may be available
in the server error log.
Fairly obviously, not what is desired. However, if you change the '206'
in the script to a '200', the script works fine. I've searched through
the mod_perl code in a brief fashion for a condition that would cause
this, but couldn't find anything. Anyone got any ideas?
CONFIGURATION
apache 1.3.27
mod_perl 1.27
mod_ssl 2.8.11-1.3.27
httpd.conf
ServerType standalone
ServerTokens ProductOnly
Timeout 300
KeepAlive On
KeepAliveTimeout 100
MaxKeepAliveRequests 10
MinSpareServers 5
MaxSpareServers 10
StartServers 5
MaxClients 20
MaxRequestsPerChild 10
BindAddress 127.0.0.1
Port 80
User nobody
Group nobody
UseCanonicalName On
DefaultType text/plain
HostnameLookups Off
ServerSignature Off
ServerAdmin [EMAIL PROTECTED]
DocumentRoot /path/to/script/parent
ErrorLog /var/log/httpd/error_log
SetHandler perl-script
PerlHandler Apache::Registry
PerlSendHeader On
Re: [MP2] bug report startup and XML::LibXML
[EMAIL PROTECTED] wrote: Hi ! and as suggested : LIBXML2.DLL VERSION 2.4.26 XML::LibXML version 1.52 I've tested with libxml2-2.4.23 and XML::LibXML 1.53 on linux and it works just fine. I tested it with libxml2-2.4.23 and XML::LibXML 1.52 and it still segfaults. I can't reproduce the problem, and just looking at the source doesn't click anything. May be try posting your research to p5p? __ 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] bug report startup and XML::LibXML
Hi !
> and as suggested :
> LIBXML2.DLL VERSION 2.4.26
> XML::LibXML version 1.52
>I've tested with libxml2-2.4.23 and XML::LibXML 1.53 on linux
>and it works
>just fine.
I tested it with libxml2-2.4.23 and XML::LibXML 1.52
and it still segfaults.
>this looks suspicious as address: 0xabababab, as you have
>traced it. So it
>could be a bug in the ActiveState's perl or is it a standard
>one?
it is perl 58 cpan source I have rebuilt all myself debug
but the bug also happens with asperl 58
here is more precicion, I have followed the trace starting with
perl_croak :
segfault
Perl_sv_setpvn(interpreter * 0x00e7f024, sv * 0xabababab,
Perl_sv_vsetpvfn(interpreter * 0x00e7f024, sv * 0xabababab,
Perl_vmess(interpreter * 0x00e7f024, const char * 0x2818fac0
Perl_vcroak(interpreter * 0x00e7f024, const char * 0x2818fac
Perl_croak(interpreter * 0x00e7f024, const char * 0x2818fac0
`string')
---
in perl_croak
Perl_croak(interpreter * 0x00e1a024, const char * 0x2818fac0
`string') line 1350 + 17 bytes
[...]
void
Perl_croak(pTHX_ const char *pat, ...)
{
va_list args;
va_start(args, pat);
vcroak(pat, &args); <<<< LINE CALLED
/* NOTREACHED */
va_end(args);
}
[...]
variable state:
+ &args 0x0006efe4
+ args0x0006eff8 "p"
+ pat 0x2818fac0 "Bizarre SvTYPE [%ld]"
in perl_vcroak
Perl_vcroak(interpreter * 0x00e1a024, const char * 0x2818fac0
`string', char * * 0x0006efe4) line 1241 + 17 bytes
void
Perl_vcroak(pTHX_ const char* pat, va_list *args)
{
char *message;
HV *stash;
GV *gv;
CV *cv;
SV *msv;
STRLEN msglen;
if (pat) {
msv = vmess(pat, args); <<<<<
Re: [MP2] bug report startup and XML::LibXML
[EMAIL PROTECTED] wrote:
Hi
here is a revised complete report bug
and as suggested :
LIBXML2.DLL VERSION 2.4.26
XML::LibXML version 1.52
I've tested with libxml2-2.4.23 and XML::LibXML 1.53 on linux and it works
just fine.
[...]
output ok but apache segfault
---
here is a complete debug trace (this one is certified exact)
---
source in perl5.8.0\sv.c line 4020
[...]
void
Perl_sv_setpvn(pTHX_ register SV *sv, register const char *ptr,
register STRLEN len)
{
register char *dptr;
SV_CHECK_THINKFIRST(sv); <<<<
if (!ptr) {
(void)SvOK_off(sv);
return;
}
[...]
Perl_sv_setpvn(interpreter * 0x00d84344, sv * 0xabababab, const
char * 0x28194f90 `string', unsigned int 0) line 4020 + 3 bytes
Perl_sv_vsetpvfn(interpreter * 0x00d84344, sv * 0xabababab,
this looks suspicious as address: 0xabababab, as you have traced it. So it
could be a bug in the ActiveState's perl or is it a standard one?
const char * 0x2818fac0 `string', unsigned int 20, char * *
0x0006efe4, sv * * 0x, long 0, char * 0x) line
7629 + 20 bytes
Perl_vmess(interpreter * 0x00d84344, const char * 0x2818fac0
`string', char * * 0x0006efe4) line 1096 + 40 bytes
Perl_vcroak(interpreter * 0x00d84344, const char * 0x2818fac0
`string', char * * 0x0006efe4) line 1241 + 17 bytes
Perl_croak(interpreter * 0x00d84344, const char * 0x2818fac0
`string') line 1350 + 17 bytes
Perl_sv_dup(interpreter * 0x00d84344, sv * 0x0006f6e8,
clone_params * 0x0006fdf0) line 9297 + 26 bytes
Though the good thing is that it happens on croak (something went wrong). So
perhaps you can check why does it happen in first place. I'd at the above frame.
__
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
[MP2] bug report startup and XML::LibXML
Hi
here is a revised complete report bug
> Hi
>
> on
> SERVER_SOFTWARE: Apache/2.0.44 (Win32) mod_perl/1.99_08-dev
> Perl/v5.8.0
and as suggested :
LIBXML2.DLL VERSION 2.4.26
XML::LibXML version 1.52
everything rebuild debug
test code
---
use testxml(); (in startup.pl)
testxml
---
package testxml;
use strict;
use warnings;
use XML::LibXML();
my $base='c:/apache2/mason';
our $promod=
XML::LibXML->new->parse_string("");
print "tostring: ",$promod->toString ;
1;
problem is
output ok but apache segfault
---
here is a complete debug trace (this one is certified exact)
---
source in perl5.8.0\sv.c line 4020
[...]
void
Perl_sv_setpvn(pTHX_ register SV *sv, register const char *ptr,
register STRLEN len)
{
register char *dptr;
SV_CHECK_THINKFIRST(sv); <<<<
Re: Internal redirect to method handler bug?
On Fri, 3 Jan 2003, Dave Rolsky wrote:
> A user on the Mason list reported a problem when the used an internal
> redirect pointed at a location handled by Mason. What was happening is
> that the HTML::Mason::ApacheHandler module, which has a _method_ handler
> sub ("sub handler ($$)") was being called without a package name (just $r)
> because of the internal redirect.
>
> I tried to make a bare bones config that duplicated the problem, but my
> really simple config worked just fine. Does this bug ring any bells?
Aha! I just found this in the archives (which I looked at before posting,
but not carefully enough):
http://marc.theaimsgroup.com/?l=apache-modperl&m=101236133418008&w=2
The above message says this happened with version 1.25 & 1.26, but the
Mason user who reported the problem is using 1.27, so it hasn't been fixed
yet.
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
Internal redirect to method handler bug?
A user on the Mason list reported a problem when the used an internal
redirect pointed at a location handled by Mason. What was happening is
that the HTML::Mason::ApacheHandler module, which has a _method_ handler
sub ("sub handler ($$)") was being called without a package name (just $r)
because of the internal redirect.
I tried to make a bare bones config that duplicated the problem, but my
really simple config worked just fine. Does this bug ring any bells?
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
[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: [mp 2] Bug report - mod-perl install process.
Ian Stuart wrote: Server Version: Apache/2.0.39 (Unix) mod_perl/1.99_07-dev Perl/v5.6.1 I believe that the install process does not test for the presence (or lack of..) of the /modules directory. This causes a problem during the mod_perl installation as the pseudo-command "cp $SOURCE/mod_perl.so $SERVER/modules" creates a large file called "modules", not a file called "mod_perl.so" within a directory called "modules" [...] Indeed, it doesn't. Thanks for the report. Does the following patch solve the problem? I'm not quite sure how portable it is, but neither ExtUtils::MakeMaker nor %Config provide entries for test_d and mkdir. Index: lib/Apache/Build.pm === RCS file: /home/cvs/modperl-2.0/lib/Apache/Build.pm,v retrieving revision 1.107 diff -u -r1.107 Build.pm --- lib/Apache/Build.pm 29 Aug 2002 02:00:56 - 1.107 +++ lib/Apache/Build.pm 11 Nov 2002 15:37:06 - @@ -1057,6 +1057,7 @@ lib: $(MODPERL_LIB) install: + test -d $(MODPERL_AP_LIBEXECDIR) || mkdir $(MODPERL_AP_LIBEXECDIR) $(MODPERL_TEST_F) $(MODPERL_LIB_DSO) && \ $(MODPERL_CP) $(MODPERL_LIB_DSO) $(MODPERL_AP_LIBEXECDIR) -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [BUG] Losing GET/POST-data
[...] Basically we are losing data sent to a mod_perl program. We request the page "page.fxml?name=al&adress=sweden&problem=huge". When our program receives this request it will only be "page.fxml" without any of the arguments sent. [...] I haven't followed the original thread, so I apologize if I repeat somebody else here. But from your description I'd suggest the following: You have to narrow the problem down after you are able to reproduce the problem at will. That means that you should use try to emulate multiply requests, for example with ab. See: http://perl.apache.org/docs/1.0/guide/performance.html#Benchmarking_Applications If you are able to do that and you know that the problem is on the server side and not caused by the clients who mess up with hidden fields or form elements. Next try to figure out who's causing the problem (assuming that it's a server side prob). e.g. this section uses three different ways to extract params: http://perl.apache.org/docs/1.0/guide/performance.html#Apache__args_vs__Apache__Request__param_vs__CGI__param Do you get the problem with all of them? Hope this helps. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:stas@;stason.org http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com
Re: Suspected Apache::AuthenNTLM Bug
> > With ColdFusion you can call the same page eg the line_main2.cfm can be > called from the line_main2.cfm with different parameters. Unfortunately > the client PC does not seem to pass the NTLM/Basic Authorization Header > the second time the page is called. > Maybe this is handled via a subrequest. To test this I send you the newest version. Please install it and set PerlSetVar ntlmdebug 2 run your request and send me the output from the httpd error log Gerald - Gerald Richterecos electronic communication services gmbh Internetconnect * Webserver/-design/-datenbanken * Consulting Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131 WWW:http://www.ecos.de Fax: +49 6133 925152 -
BUG in $r->uri ?
I know I shouldn't, but I have a URI that goes: "a_silly_clients_filename 2 . jpg" And when I try: $r->log_error ( $r->uri ); the result is: [Fri Nov 08 09:59:37 2002] [error] a_silly_clients_filename 2.jpg Is this real, or is it me? Thanks, lee Lee Goddard
Re: Suspected Apache::AuthenNTLM Bug
Hi there, On 8 Nov 2002, Brett Hales wrote: > I believe that there is a bug in the Apache::AuthenNTLM module. Did you see this? 73, Ged. -- Date: Thu, 7 Nov 2002 17:46:15 -0600 (CST) From: Gerald Combs <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: NTLM Authentication patch We recently installed AuthenNTLM where I work, and ran into the POST problems described in the thread at http://marc.theaimsgroup.com/?t=10317736546&r=1&w=2 After looking through a couple of network traces I think I've found the problem. It appears that after IE authenticates via NTLM, it sends type 1 messages for subsequent requests during a keepalive session. This is fine and dandy unless you're sending a POST request - when it sends the type 1 message, it also sends a "Content-length: 0", and doesn't append the POST data. Since the browser has successfully authenticated itself earlier in the keepalive session, AuthenNTLM validates the request and a POST with no accompanying POST data gets passed to the server. Attached is a patch against the 0.21 release that fixes this behavior (in our environment, at any rate). I know very little about NTLM authentication and mod_perl coding, so the patch may not be entirely correct.
Suspected Apache::AuthenNTLM Bug
I believe that there is a bug in the Apache::AuthenNTLM module. Configuration: I have an Apache server with ColdFusion MX 6 installed, there is a requirement for NTLM authentication with the server. I implemented the PerlAuthenHandler Apache::AuthenNTLM to solve this problem. Problem: With ColdFusion you can call the same page eg the line_main2.cfm can be called from the line_main2.cfm with different parameters. Unfortunately the client PC does not seem to pass the NTLM/Basic Authorization Header the second time the page is called. An error appears in the error.log [Fri Nov 8 09:03:58 2002] [error] access to /cf_dev/objectives/line_main2.cfm failed for , reason: Bad/Missing NTLM/Basic Authorization Header for /cf_dev/objectives/line_main2.cfm Configuration: Apache::AuthenNTLM (version 0.21) Server version: Apache/1.3.27 (Unix) httpd.conf Alias /cf_dev/objectives/ "/baewwwroot/cf_dev/objectives/" Options -Indexes FollowSymLinks MultiViews PerlAuthenHandler Apache::AuthenNTLM AuthType ntlm AuthName "Windows Authentication Required" require valid-user PerlAddVar ntdomain "BAEA baeapdc sbntfp1" PerlAddVar ntdomain "BAEADEV bantdev1" PerlSetVar defaultdomain BAEA -- Brett Hales
Minor bug in AuthCookieDBI ?
Hi - I am wondering if there is a bug in AuthCookieDBI.pm?
There is function group which is called to verify the user's group when there is a
"Require group" directive. It starts like this:
sub group($$\@)
{
my( $self, $r, @groups ) = @_;
When more than one group is specified in the Require group directive, eg. "Require
group group1 group2 group3", I would expect @groups to be an array with 3 elements,
one for each of group1, group2, and group3.
But what I get is a single string (or an array with one element depending on how you
look at it) which has the entire groups string from the directive, e.g. "group1 group2
group3".
For now my workaround is to just split the string.
But shouldn't it either already be split, or be passed in as a string, not a list?
GV
Re: [BUG] Losing GET/POST-data
Hello.
I have posted a note here before, and want to thank those that took time
to try to solve this strange problem, but unfortunately none of the
suggestions have helped us so far, except for helping us ruling out things
that could have been incorrect.
Now I have received some more information since the last time so I'll try
again.
I have tried to be brief, but this is a complicated problem so it does
need some text to fully understand.
Basically we are losing data sent to a mod_perl program. We request the
page "page.fxml?name=al&adress=sweden&problem=huge". When our program
receives this request it will only be "page.fxml" without any of the
arguments sent.
Ok, first of all, yes we use the extension fxml - we want to mix
non-mod_perl files among my mod_perl files so we have set the apache up to
run mod_perl only on .fxml extension files. Works fine (apart from our
problem), but the problem happens even when we parse all files.
Second, we dont get this problem all the time. It occurs very infrequently
and (what appears to be) for total random reasons. On one machine (we have
several installations of this program) we will get the error 5 minutes
after the machine started up and after a restart not for 24 hours. On one
we will get it after 5-10 requests being sent to the apache server after
restart and on another not a single error for 24 hours of continous very
hard use (test scripts accessing like mad).
Third, which might be important, we almost always use vhosts to set up
different instances of sites that will run the code.
We have a temporary solution to the problem, being that we restart the
server every second hour. This has reduced the number of errors we get,
but not eliminated them. One day (24 hour period) we can have 100-150
errors on one site, orther days we can get 700-800 errors (when we send
roughly 17500 requests to the server during this time period). And this is
when we do the restarts every sencond hour. If we don't the amount of
errors will be up to almost half of the requests.
The apache logs the request correctly to the access log but when we try to
access the arguments in mod_perl they will just not be there anymore. We
assume that the apache hands the data over to mod_perl who then hand it
over to our program, this is what seems to go wrong on occasion.
What we would like to do is find a way to track a request all the way
through the apache and mod_perl to, finally, our program.
Can this be done easily?
Has anyone else encountered a problem like this?
Does anyone know anything about this problem?
Help! :o)
-
Technical information:
Solaris/mod_perl 1.25/apache 1.3.19
Debian GNU/Linux, latest stable/mod_perl 1.26/apache 1.3.23
Both use Perl 5.6.1
lines from the httpd.conf file:
PerlModule MyProjects::Project1
sethandler perl-script
perlhandler MyProjects::Project1::handler
options execcgi followsymlinks includes
---
lines from the Project1.pm file:
sub handler($)
{
$^W = 1; # gripe about the little things
my $r = shift;
my $apr;
my %parm;
$apr = Apache::Request->new($r);
if($r->method() eq 'POST' || $r->method() eq 'GET')
{
my @keys = $apr->param();
foreach my $key (@keys)
{
$parm{$key} = $apr->param($key);
print STDERR "Inargs: $key = " . $parm{$key} . "\n";
}
}
.
.
.
---
(this will from time to time not generate anything)
Thankful for any and all help that can help us find this annoying problem.
/Hakan
-
Hi! I'm a .signature virus!
Copy me into your .signature file to help me spread!
[mp 2] Bug report - mod-perl install process.
Server Version: Apache/2.0.39 (Unix) mod_perl/1.99_07-dev Perl/v5.6.1
I believe that the install process does not test for the presence (or
lack of..) of the /modules directory.
This causes a problem during the mod_perl installation as the
pseudo-command "cp $SOURCE/mod_perl.so $SERVER/modules" creates a large
file called "modules", not a file called "mod_perl.so" within a
directory called "modules"
To demonstrate the issue, I did the following:
1) create an apache with the configure options of:
TARGET=httpd2.mod_perl ./configure --build=i686
--enable-layout=Lucas.mod_perl --enable-mime-magic --enable-expires
--enable-info --enable-cgi --enable-include --enable-negotiation
--disable-userdir --with-program-name=httpd2_mod_perl --with-mpm=prefork
(config.layout contains:
prefix:/home/cpan/apache2.mod_perl
exec_prefix: /home/cpan
bindir:${exec_prefix}/bin
sbindir: ${exec_prefix}/sbin
libdir:${exec_prefix}/lib
libexecdir:${exec_prefix}/libexec
mandir:${prefix}/man
sysconfdir:${prefix}/etc
datadir: ${prefix}/share
iconsdir: ${datadir}/icons
htdocsdir: ${datadir}/htodcs
manualdir: ${htdocsdir}/manual
cgidir:${datadir}/cgi-bin
includedir:${prefix}/include
localstatedir: ${prefix}/var
runtimedir:${prefix}/var/run
logfiledir:${localstatedir}/log
proxycachedir: ${localstatedir}/proxy
infodir: ${localstatedir}/info
installbuilddir: ${sysconfdir}/build
errordir: ${datadir}/error
)
Build and install Mod-Perl with:
perl Makefile.PL MP_DEBUG=1 MP_INST_APACHE2=1
MP_AP_PREFIX=/home/cpan/apache2.mod_perl
then make && make install.
This creates a large file called "modules" in the $SERVERROOT directory.
If I physically make the modules/ directory after step 1, then the
mod_perl.so file is copied across correctly.
I've also tested this with httpd 2.0.43, and it does the same think --
no .../modules directory is created.
Ta..
--
--==++
Ian Stuart: Edinburgh University Data Library.
Information is not knowledge
Knowledge is not wisdom
Wisdom is not truth
Truth is not beauty
Beauty is not love
Love is not music
-- Mary.
Personal web site: http://lucas.ucs.ed.ac.uk/
(bug report) SIGALRM problem in mod-perl causes stuck Apache processes.
I have recently seen a number of stuck processes on an Apache server I run. The problem is associated with events which appear to be attacks by the Slapper worm. The server's OpenSSL has been upgraded, so actual penetration by Slapper does not occur. However the stuck processes are inconvenient, and threaten DoS. I have analysed the problem and discovered that incorrect manipulation of the handling of alarm signals by mod-perl is causing some Apache timeouts to fail. Software versions: Solaris 8 (SPARC 64 bit) Apache 1.3.26 perl 5.6.1 mod-perl 1.26 (source shows same problem in 1.27) mod-ssl2.8.10 OpenSSL0.9.6e The details of the problem are as follows: If the processing of a request to the server involves any perl handlers, mod-perl attempts to save and restore the Apache's handler for SIGALRM. The handler is saved at line 408 of perl_config.c and restored at line 1122 of mod_perl.c. (line numbers are from mod-perl version 1.26). The save/restore is done using the perl utility functions rsignal_state and rsignal. In perl 5.6.1, rsignal sets the SA_RESTART flag regardless of the saved state (util.c line 2509). The original SIGALRM state is set by Apache by a call of the libc function signal. This does leaves SA_RESTART clear. Thus, the first use of mod-perl in the life of an Apache child process changes the handling of SIGALRM. Thereafter, some, but not all, Apache timeouts fail to work. Two timeouts which I know to be affected by this are the timeout associated with the configuration directive KeepAliveTimeout, and that associated with the mod-ssl warning message "mod_ssl: SSL handshake timed out". Signal handling is greatly changed in perl 5.8. I believe that this problem will not occur with that version of perl unless it is compiled with PERL_OLD_SIGNALS. I think that it is the code in perl itself which is wrong. However, I also believe that the problem is serious enough to warrant a maintenance release of mod-perl which programs round the broken behaviour of rsignal in the perl versions which are actually in use at present. -- Charles Jardine - Computing Service, University of Cambridge [EMAIL PROTECTED]Tel: +44 1223 334506, Fax: +44 1223 334679
Re: [BUG] Losing GET/POST-data
Hi Hakan,
CGI::Minimal has a "truncate" function that picks up invalid CGI
data ... this may help.
Nigel
> On Wed, 2 Oct 2002, Wes Cravens wrote:
>
> > On 02 Oct 2002 15:23 GMT I wrote:
> >
> > >
> > > Hi!
> > >
> > > We're developing a perl module for apache/mod_perl, but have encountered a
> > > really strange problem.
> > >
> > > After 'a while' we seem to lose the data sent to the apache-server, at
> > > least it never reaches our module.
> >
> >
> >
> > > Recently we switched from using the standard Apache request-object to
> > > using the Apache::Request one, for the added functionality, but this has
> > > not had any effect at all as far as we can tell, and the bug keeps
> > > happening...
> >
> > I ran into a problem that the param parts of a request were flushed
> > when read for the first time... so if you lose them (don't store them)
> > then you cannot access them again.
>
> Yep, noticed this myself when re-writing it to check the input, should
> have posted this first perhaps, but anyway, this is basically how we
> handle the input:
>
> sub handler($)
> {
> $^W = 1; # gripe about the little things
> my $r = shift;
> my %parm;
>
> if ($r->method() eq 'POST') { %parm = $r->content(); }
> elsif ($r->method() eq 'GET') { %parm = $r->args(); }
>
>
>
> And now, after the re-write with Apache::Request
>
> sub handler($)
> {
> $^W = 1; # gripe about the little things
> my $r = shift;
> my $apr;
> my %parm;
>
> $apr = Apache::Request->new($r);
>
> if($r->method() eq 'POST' || $r->method() eq 'GET')
> {
> my @keys = $apr->param();
>
> foreach my $key (@keys)
> {
> $parm{$key} = $apr->param($key);
> }
> }
>
>
>
> So.. I can't really see how that would make us lose the parameters,
> especially since we doesn't lose them all the time, which was the case
> when I tried to get the same value twice...
>
>
> [Back to Wes]
> > If you are not already, then try
> >
> > $apr = HTTP::Request->instance($r); instead...
> >
>
> We use ->new now. Since we always only create one instance of it I
> thought there was no difference. Is instance known to be safer or so?
>
> Also got the hint that this could somehow be connected to caching, but
> since we when we output debug-messages see that handler() is called, with
> no parameters in $r, I don't see how this could be. Any comments, and
> suggestions of fix if this might be the problem?
>
> Thanks again,
> Hakan
>
> ([EMAIL PROTECTED])
>
> -
> Hi! I'm a .signature virus!
> Copy me into your .signature file to help me spread!
>
--
Nigel Hamilton
Turbo10 Metasearch Engine
email: [EMAIL PROTECTED]
tel:+44 (0) 207 987 5460
fax:+44 (0) 207 987 5468
http://turbo10.com Search Deeper. Browse Faster.
Re: [BUG] Losing GET/POST-data
On Wed, 2 Oct 2002, Wes Cravens wrote:
> On 02 Oct 2002 15:23 GMT I wrote:
>
> >
> > Hi!
> >
> > We're developing a perl module for apache/mod_perl, but have encountered a
> > really strange problem.
> >
> > After 'a while' we seem to lose the data sent to the apache-server, at
> > least it never reaches our module.
>
>
>
> > Recently we switched from using the standard Apache request-object to
> > using the Apache::Request one, for the added functionality, but this has
> > not had any effect at all as far as we can tell, and the bug keeps
> > happening...
>
> I ran into a problem that the param parts of a request were flushed
> when read for the first time... so if you lose them (don't store them)
> then you cannot access them again.
Yep, noticed this myself when re-writing it to check the input, should
have posted this first perhaps, but anyway, this is basically how we
handle the input:
sub handler($)
{
$^W = 1; # gripe about the little things
my $r = shift;
my %parm;
if ($r->method() eq 'POST') { %parm = $r->content(); }
elsif ($r->method() eq 'GET') { %parm = $r->args(); }
And now, after the re-write with Apache::Request
sub handler($)
{
$^W = 1; # gripe about the little things
my $r = shift;
my $apr;
my %parm;
$apr = Apache::Request->new($r);
if($r->method() eq 'POST' || $r->method() eq 'GET')
{
my @keys = $apr->param();
foreach my $key (@keys)
{
$parm{$key} = $apr->param($key);
}
}
So.. I can't really see how that would make us lose the parameters,
especially since we doesn't lose them all the time, which was the case
when I tried to get the same value twice...
[Back to Wes]
> If you are not already, then try
>
> $apr = HTTP::Request->instance($r); instead...
>
We use ->new now. Since we always only create one instance of it I
thought there was no difference. Is instance known to be safer or so?
Also got the hint that this could somehow be connected to caching, but
since we when we output debug-messages see that handler() is called, with
no parameters in $r, I don't see how this could be. Any comments, and
suggestions of fix if this might be the problem?
Thanks again,
Hakan
([EMAIL PROTECTED])
-
Hi! I'm a .signature virus!
Copy me into your .signature file to help me spread!
Re: [BUG] Losing GET/POST-data
On 02 Oct 2002 15:23 GMT you wrote:
>
> Hi!
>
> We're developing a perl module for apache/mod_perl, but have encountered a
> really strange problem.
>
> After 'a while' we seem to lose the data sent to the apache-server, at
> least it never reaches our module.
> Recently we switched from using the standard Apache request-object to
> using the Apache::Request one, for the added functionality, but this has
> not had any effect at all as far as we can tell, and the bug keeps
> happening...
I ran into a problem that the param parts of a request were flushed when read for the
first time... so if you lose them (don't store them) then you cannot access them again.
If you are not already, then try
$apr = HTTP::Request->instance($r); instead...
Here is some code that I use to strip a request down and then store in a hashref for
each request. Almost every handler that I use calls this in the first instance. This
way $r will remain intact and $r_info is a really handy hashref.
sub handler {
my $r_info = r_info($r);
}
sub r_info {
my $r = shift;
my $s = $r->server;
my $c = $r->connection;
my $apr = Apache::Request->instance($r);
#Parse / Collect the parameters.
my %params;
foreach ($apr->param) {
$params{$_} = $apr->param($_);
}
my $r_info_headers = [r_headers($r)]->[1];
my $cookies = fetch CGI::Cookie;
my %hash;
undef %hash;
%hash = (
server_name => $r->get_server_name(),
server_port => $r->get_server_port(),
doc_root => $r->document_root(),
path_info =>$r->path_info(),
method => $r->method(),
uri => $r->uri(),
params => \%params,
protocol => $r->protocol(),
server_admin => $s->server_admin(),
server_hostname=>$s->server_hostname(),
remote_ip =>$c->remote_ip(),
headers => $r_info_headers,
cookies => $cookies
);
return (\%hash);
}
sub r_headers {
my $r = shift;
my (@list, $header, @headers_list, $value, %headers_hash);
@list = $r->headers_in;
while ($header = shift @list) {
$value = shift @list;
push (@headers_list, $header);
$headers_hash{$header} = $value;
}
return (\@headers_list, \%headers_hash);
}
[BUG] Losing GET/POST-data
Hi! We're developing a perl module for apache/mod_perl, but have encountered a really strange problem. After 'a while' we seem to lose the data sent to the apache-server, at least it never reaches our module. We have absolutely no idea what might be causing this, and we realize it isn't an easy question to ask either, since we have never been able to reproduce the error on command. Sometimes it's there, sometimes not. It seems to come more frequently when the apache has been up and running for quite some time though, so our current 'solution' is to restart the apache every 3rd hour, but this doesn't completely solve the problem either. We have encountered the bug on several versions of both apache and mod_perl, on different os's: Solaris/mod_perl 1.25/apache 1.3.19 Debian/mod_perl 1.26/apache 1.3.23 We have also seen it both in the compiled versions and in the standard distributions. Recently we switched from using the standard Apache request-object to using the Apache::Request one, for the added functionality, but this has not had any effect at all as far as we can tell, and the bug keeps happening... It is possible that it has increased somewhat with increased number of vhosts, but we can't say for sure. Our perl module is 2k+ lines of perl-code, using other self-made modules of another 6k+ lines, + several standard modules, if that is of any help. Everything else seems to be fine, and no error-logs show anything. We have searched plenty on the web, in mailing list archives and such, but have so far never seen it mentioned. Does anyone at all know what this could be? Any pointers at all regarding any possible solution to this problem would be much appreciated. Thanks, Hakan Nilsson [EMAIL PROTECTED] - Hi! I'm a .signature virus! Copy me into your .signature file to help me spread!
bug with IO::Scalar IO::String Text::Iconv and XML
Hi
here is a program that shows something wrong when using
Text::Iconv with
IO::Scalar or IO::String
read a sample xml file, with an accented character, after
xml parsing (which translates to utf-8), translate back to iso-
8859-1.
also prepare a simple utf-8 string with text::iconv
problem :
when print is done with IO::Scalar or IO::String redirection,
conversion fails.
pascal
here the XML is read with XML::Simple or XML::LibXML,
but this is the same with XML::XPath
note Text::Iconv->raise_error(1) raises no error.
source program test:
use warnings;
use XML::Simple;
use Text::Iconv;
use XML::LibXML ;
Text::Iconv::->raise_error(1);
my $string=q{étude};
my $string2=Text::Iconv->new("iso-8859-1","utf-8")->convert
("étude");
my $doc =XML::LibXML->new->parse_string($string) ;
my $ref=XML::Simple->new->XMLin($string);
my $C= Text::Iconv->new('UTF-8','ISO-8859-1');
print "\n--\n";
print $doc->toString, "\n raw:", $ref,"\tconv:", $C->convert
($ref);
print "\n str2:", $string2,"\tconv:", $C->convert($string2);
--
source program calltest
-
use IO::Scalar;
use IO::String;
my $page;
my $CACHE =new IO::Scalar \$page ;
select $CACHE;
do 'test' ;
select STDOUT;
print $page ;
my $io=IO::String->new(my $tocache);
select $io ;
do 'test' ;
select STDOUT ;
print $tocache ;
do 'test' ;
---
output of PERL test
--
--
étude
raw:étude conv:étude
str2:étudeconv:étude
raw print is UTF-8, conv print is iso
XML output is in iso directly
Iconv conversion is successful
raw and str2 are the same
all correct
now look at other output :
==
output of PERL calltest
IO::Scalar --
étude
raw:étude conv:étude
str2:étude conv:étude
IO::String--
étude
raw:étude conv:étude
str2:étude conv:étude
STDOUT--
étude
raw:étude conv:étude
str2:étudeconv:étude
=
ICONV fails to convert when IO redirection,
looks like characters are not the same between raw and
string2, which
both should be utf-8 translation of "étude"
the toString method of LIbXML seems to output back in iso-8859-
1, without explicit
translation, but this fails with IO redirection too.
Accédez au courrier électronique de La Poste : www.laposte.net ; 3615 LAPOSTENET (0,13
/mn) ; tél : 08 92 68 13 50 (0,34/mn)"
Re: installation bug with Apache v2.0.42
Em Wed, Sep 25, 2002 at 10:40:53AM -0700, Eugene Eric Kim escreveu:
> format of the macros in include/ap_release.h between 2.0.40 and 2.0.42.
> AP_SERVER_BASEREVISION is now:
>
> #define AP_SERVER_BASEREVISION AP_SERVER_MINORREVISION "." AP_SERVER_PATCHLEVEL
>
> instead of simply:
>
> #define AP_SERVER_BASEREVISION "2.0.42"
>
> This breaks the httpd_version method in Apache/Build.pm.
Try this patch, is what I'm using here:
--- mod_perl-1.99_05/lib/Apache/Build.pm.orig 2002-09-19 18:44:56.0 -0300
+++ mod_perl-1.99_05/lib/Apache/Build.pm2002-09-19 18:46:32.0 -0300
@@ -740,14 +740,17 @@
return undef;
};
-my $version;
+my ($version,$maj,$min,$pat);
while(<$fh>) {
-next unless /^\#define\s+AP_SERVER_BASEREVISION\s+\"(.*)\"/;
-$version = $1;
-last;
+$maj = $1 if /^#define\s+AP_SERVER_MAJORVERSION\s+\"(.*)\"/;
+$min = $1 if /^#define\s+AP_SERVER_MINORVERSION\s+\"(.*)\"/;
+$pat = $1 if /^#define\s+AP_SERVER_PATCHLEVEL\s+\"(.*)\"/;
+$maj && $min && $pat && last;
}
+$version = "$maj.$min.$pat";
+
close $fh;
$self->httpd_version_cache($dir, $version);
installation bug with Apache v2.0.42
I found a minor installation bug in both modperl v1.99-5. (The same bug also seems to be in the latest modperl-2.0 CVS tree.) The bug occurs when you try to install modperl 2 with the latest version of Apache (2.0.42). For whatever reason, the Apache folks changed the format of the macros in include/ap_release.h between 2.0.40 and 2.0.42. AP_SERVER_BASEREVISION is now: #define AP_SERVER_BASEREVISION AP_SERVER_MINORREVISION "." AP_SERVER_PATCHLEVEL instead of simply: #define AP_SERVER_BASEREVISION "2.0.42" This breaks the httpd_version method in Apache/Build.pm. I got around it by simply changing the AP_SERVER_BASEREVISION in include/ap_release.h to the latter format. The "correct" solution depends on how stable the macro format will be for future versions of Apache. If it's going to stay the way it is, httpd_version needs to be modified to search for other macros as an alternative method for computing the version. -Eugene -- +=== Eugene Eric Kim = [EMAIL PROTECTED] = http://www.eekim.com/ ===+ | "Writer's block is a fancy term made up by whiners so they| += can have an excuse to drink alcohol." --Steve Martin ===+
Re: BUG: Apache::Cookie v1.0
On Monday, 2002-09-23 at 11:11:02 -0400, darren chamberlain wrote:
> * Michael McLagan <[EMAIL PROTECTED]> [2002-09-21 11:45]:
> > There is a bug in Apache::Cookie. It doesn't handle a cookie with
> > zero bytes in it!
> This is because Apache::Cookie is implemented in C, and C uses NULL as
> the end of string terminator.
No quite accurate. C has no concept of a string. There are a number of
library functions for string handling that use '\0' as the string
terminator.
If somebody rewrites Apache::Cookie to replace those functions, it will
be able to handle such cookies.
> This is probably something that needs to be done in Perl, since I doubt
> there's a way to check for "embedded" NULLs in a string in C...
/* We assume there will always a '\0' to be found. */
char *
find_nul(char *str)
{
while (*str) {
str++;
}
return str;
}
What interests me much more is *why* a cookie should be able to contain
*any* control character. If you want binary data in a cookie, you should
encode it somehow.
If the '\0' was a '\n', things would be much more interesting ...
Lupe Christoph
--
| [EMAIL PROTECTED] | http://www.lupe-christoph.de/ |
| Big Misunderstandings #6398: The Titanic was not supposed to be|
| unsinkable. The designer had a speech impediment. He said: "I have |
| thith great unthinkable conthept ..." |
Re: BUG: Apache::Cookie v1.0
* Michael McLagan <[EMAIL PROTECTED]> [2002-09-21 11:45]: > There is a bug in Apache::Cookie. It doesn't handle a cookie with > zero bytes in it! This is because Apache::Cookie is implemented in C, and C uses NULL as the end of string terminator. This is probably something that needs to be done in Perl, since I doubt there's a way to check for "embedded" NULLs in a string in C... (darren) -- If you wish to drown, do not torture yourself with shallow water.
Re: BUG: Apache::Cookie v1.0
Once upon a time, I wrote: > There is a bug in Apache::Cookie. It doesn't handle a cookie > with zero bytes in it! A clarification, it's not a zero length cookie that is mishandled, it's a cookie with an embedded NUL (zero) character. Michael
BUG: Apache::Cookie v1.0
Hello,
There is a bug in Apache::Cookie. It doesn't handle a cookie with zero
bytes in it!
$value = "ABCD" . chr(0) . "EFGH";
$cookie = Apache::Cookie->new($request, -name=> 'oatmeal', -value=> $value,
-domain=>$ENV{'SERVER_NAME'}, -path=>"/");
print $cookie->as_string;
The output looks like:
oatmeal=ABCD; domain=my.web.server.com; path=/; expires=0
Where did the rest of my cookie go?!
Should I not have gotten:
oatmeal=ABCD%00EFGH; domain=my.web.server.com; path=/; expires=0
Michael
Re: Morning bug w/out using Apache::DBI?
Your problem doesn't sound like something that Apache::DBI would cause. Deadlock problems are caused by conflicting updates, which could only be coming from your code. > I'm not positive but maybe it seemed like there were > stale handlers lying around that weren't being closed If you put database handles in globals or in closures, or in some data structure (like an object) that gets put into a global, it will stay around just like it does with Apache::DBI. Is it possible you did something like partially read a set of results and leave the rest dangling? You could try putting some $sth->finish() statements in your code to deal with this. > Regardless, I was wondering what a solution would be for this situation. > Currently, I do not do a ping if a handler goes stale and attempt a > reconnect. Should I implement this feature? No, you would just be rewriting Apache::DBI. - Perrin
Morning bug w/out using Apache::DBI?
Hi! I recently made an attempt to upgrade other web software to mod_perl 1.26 (compiled statically, running on Solaris 2.6). We're using Sybase 11.9.2 for this application as the db backend. When I initially converted the site over to mod_perl, I started off using Apache::DBI by placing it in the startup.pl script that I have Apache use when loading mod_perl. Apparently, that night, the dataserver began experiencing deadlocking. Here are some of the error messages encountered in the apache logs and through one of our cron jobs: DBD::Sybase::db rollback failed: OpenClient message: LAYER = (1) ORIGIN = (1) SEVERITY = (1) NUMBER = (49) Message String: ct_send(): user api layer: external error: This routine cannot be called because another command structure has results pending. DBD::Sybase::db rollback failed: OpenClient message: LAYER = (1) ORIGIN = (1) SEVERITY = (1) NUMBER = (50) Message String: ct_cmd_alloc(): user api layer: external error: The connection has been marked dead. DBD::Sybase::db prepare failed: OpenClient message: LAYER = (4) ORIGIN = (1) SEVERITY = (5) NUMBER = (1) Message String: ct_results(): protocol specific layer: external error: There is a tds protocol error. Premature end of the datastream was encountered. Your server command (family id #0, process id #16) was deadlocked with another process and has been chosen as deadlock victim. Re-run your command. When I restarted the Apache server, it seemed to have cleaned this situation up temporarily. I ended up removing Apache::DBI from the startup.pl script to see if this would resolve this issue. This morning apparently, similar problems were encountered. I didn't see the same error messages arise this morning in the Apache logs, but the same error appeared this morning: DBI->connect(interfaces=;server=;database=) failed: OpenClient message: LAYER = (5) ORIGIN = (3) SEVERITY = (5) NUMBER = (6) Message String: ct_connect(): network packet layer: internal net library error: Net-Library operation terminated due to disconnect These connect errors seemed to have affected the Sybase server in terms of connectivity. I'm not positive but maybe it seemed like there were stale handlers lying around that weren't being closed, perhaps preventing other handlers from being able to connect since the maximum number of open connections was being exceeded (well, that's my theory. Please correct me if I'm wrong here). Also, these errors didn't come about until roughly 5 hours after the Apache server was restarted with the mod_perl applications in place. There was little activity on the web server side in relation to those mod_perl applications. Regardless, I was wondering what a solution would be for this situation. Currently, I do not do a ping if a handler goes stale and attempt a reconnect. Should I implement this feature? Are there other considerations to deal with in this situation? Note that this is an internal server which isn't heavily used so I'm not worried about receiving a few million hits a second. Thanks for any help. --Keith
