Re: 1.24 to 1.24_01 spinning httpds on startup (solved)
On Tue, 28 Nov 2000, Michael J Schout wrote: Perl $PerlRequire = '/some/path/file.pl'; /Perl Changing this to: Perl push @PerlRequire, '/some/path/file.pl'; /Perl Fixed the problem under 1.24_01 for me and everything appears to be kosher now. Maybe the behavior of PerlRequire has changed between 1.24 and 1.24_01? Hmn... Happens to me too after upgrading from 1.24 to 1.24_01 (Apache 1.3.12). #0 0x400fe7f9 in _IO_vfprintf (s=0xbf800474, format=0x81433b5 "_(eval %lu)", ap=0xbf80053c) at vfprintf.c:209 #1 0x4010c0b3 in _IO_vsprintf (string=0xbf80056c "", format=0x81433b5 "_(eval %lu)", args=0xbf80053c) at iovsprintf.c:47 #2 0x4010676f in sprintf (s=0xbf80056c "", format=0x81433b5 "_(eval %lu)") at sprintf.c:38 #3 0x811037c in Perl_pp_entereval () #4 0x80c9997 in perl_eval_sv () #5 0x808b9ee in perl_require_module () #6 0x808a126 in perl_section () #7 0x8089fac in perl_section_self_boot () #8 0x808816a in perl_cmd_require () #9 0x809ffd7 in ap_clear_module_list () #10 0x80a0423 in ap_handle_command () #11 0x8089b34 in perl_handle_command () #12 0x808a445 in perl_section () #13 0x8089fac in perl_section_self_boot () #14 0x808816a in perl_cmd_require () #15 0x809ffd7 in ap_clear_module_list () #16 0x80a0423 in ap_handle_command () #17 0x8089b34 in perl_handle_command () #18 0x808a445 in perl_section () #19 0x8089fac in perl_section_self_boot () [... repeating ...] I don't see any changes to the Perl configure code... Perl $PerlRequire = '/tmp/startup.pl'; /Perl $ cat /tmp/startup.pl warn "works?"; 1; - ask -- ask bjoern hansen - http://ask.netcetera.dk/ more than 70M impressions per day, http://valueclick.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: Apache::Carp - Error Handling under mod_perl
Can you help by explaining what this does that is different from CGI::Carp? What are you doing that is Apache specific? Could CGI::Carp do the job? If there was something you needed added to CGI::Carp, would it make sense for you to add the apache-specific function flag to CGI::Carp instead of making a brand-new module? At 12:37 AM 11/30/00 -0500, T.J. Mather wrote: I've done a lot of programming under mod_perl and I got tired of examining the error logs for errors. So I wrote a module that displays to the broswer the error (with a complete call stack) for any fatals or warnings that occur on a development server (similar to using CGI::Carp qw(fatalsToBrowser);), or emails the site administrator for errors on a production server. This has been released on CPAN as Apache::PageKit::Error, but since it doesn't depend on Apache::PageKit at all, I'm thinking of releasing it as a seperate module. Do you think this is worth doing? What should it be called? Is Apache::Carp a good name? Documentation can be found here (with the old Apache::PageKit::Error name) http://search.cpan.org/doc/TJMATHER/Apache-PageKit-0.05/lib/Apache/PageKit/Error.pm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: Apache::Carp - Error Handling under mod_perl
On Thu, 30 Nov 2000, Gunther Birznieks wrote:
Can you help by explaining what this does that is different from CGI::Carp?
What are you doing that is Apache specific? Could CGI::Carp do the job? If
there was something you needed added to CGI::Carp, would it make sense for
you to add the apache-specific function flag to CGI::Carp instead of making
a brand-new module?
Can we not burn CGI::Carp yet? :-)
I'm assuming this new module is also based on $SIG{__DIE__}... in which
case, shoot me now.
--
Matt/
/||** Director and CTO **
//||** AxKit.com Ltd ** ** XML Application Serving **
// ||** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
ETag vs Last-Modified
Does anyone know where I can find a list of browsers that use ETag in conjunction/preference to Last-Modified. --Nigel Wetters - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebDAV support in mod_perl
HTTP::DAV is a client to the WebDAV protocol, not a server. Aaron Johnson wrote: Is the HTTP::DAV module of any use? I just ran across it in TPJ. http://theoryx5.uwinnipeg.ca/CPAN/data/HTTP-DAV/DAV.html -- João Pedro Gonçalves perl -pe'$_=eofpack(c5,83,(16)+1,010*0xa,ord($0)*2-0xb,10)'/etc/passwd - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: 1.24 to 1.24_01 spinning httpds on startup (solved)
I think I remember a thread on dev that talked about this... http://archive.covalent.net/modperl-cvs/2000/09/0050.xml was maybe the cause of the change in behavior? HTH --Geoff -Original Message- From: Ask Bjoern Hansen [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 30, 2000 3:12 AM To: Michael J Schout Cc: [EMAIL PROTECTED] Subject: Re: 1.24 to 1.24_01 spinning httpds on startup (solved) On Tue, 28 Nov 2000, Michael J Schout wrote: Perl $PerlRequire = '/some/path/file.pl'; /Perl Changing this to: Perl push @PerlRequire, '/some/path/file.pl'; /Perl Fixed the problem under 1.24_01 for me and everything appears to be kosher now. Maybe the behavior of PerlRequire has changed between 1.24 and 1.24_01? Hmn... Happens to me too after upgrading from 1.24 to 1.24_01 (Apache 1.3.12). #0 0x400fe7f9 in _IO_vfprintf (s=0xbf800474, format=0x81433b5 "_(eval %lu)", ap=0xbf80053c) at vfprintf.c:209 #1 0x4010c0b3 in _IO_vsprintf (string=0xbf80056c "", format=0x81433b5 "_(eval %lu)", args=0xbf80053c) at iovsprintf.c:47 #2 0x4010676f in sprintf (s=0xbf80056c "", format=0x81433b5 "_(eval %lu)") at sprintf.c:38 #3 0x811037c in Perl_pp_entereval () #4 0x80c9997 in perl_eval_sv () #5 0x808b9ee in perl_require_module () #6 0x808a126 in perl_section () #7 0x8089fac in perl_section_self_boot () #8 0x808816a in perl_cmd_require () #9 0x809ffd7 in ap_clear_module_list () #10 0x80a0423 in ap_handle_command () #11 0x8089b34 in perl_handle_command () #12 0x808a445 in perl_section () #13 0x8089fac in perl_section_self_boot () #14 0x808816a in perl_cmd_require () #15 0x809ffd7 in ap_clear_module_list () #16 0x80a0423 in ap_handle_command () #17 0x8089b34 in perl_handle_command () #18 0x808a445 in perl_section () #19 0x8089fac in perl_section_self_boot () [... repeating ...] I don't see any changes to the Perl configure code... Perl $PerlRequire = '/tmp/startup.pl'; /Perl $ cat /tmp/startup.pl warn "works?"; 1; - ask -- ask bjoern hansen - http://ask.netcetera.dk/ more than 70M impressions per day, http://valueclick.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: RFC: DBI::Prof
Hi, I'm not quite sure, but I think the following would produce wrong results, wouldn't it? $sth1 = $dbh-prepare(...); $sth2 = $dbh-prepare(...); $sth1-execute(); $sth3 = $dbh-prepare(...); $sth2-execute(); $sth3-execute(); Michael Jacob Datum: 28.11.2000 21:12 An:mod_perl list [EMAIL PROTECTED] Betreff: RFC: DBI::Prof Nachrichtentext: I have a huge project with lots of tables, and the performance wasn't that well. So I've started to review the tables definitions and have found that some indices were missing. I was sick from doing the tracing of all possible SQL calls manually, so I wrote this simple profiler. Take a look and tell me if you think it worths releasing on CPAN... hmm, why mod_perl list... because it works under mod_perl :) In fact I didn't test it under non mod_perl but it should work as well :) Anyway, enjoy :) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ Prof.pm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: WebDAV support in mod_perl
That's the one that (used to be)|is slow... -Original Message- From: Aaron Johnson [mailto:[EMAIL PROTECTED]] Sent: Wednesday, November 29, 2000 9:26 PM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: WebDAV support in mod_perl Is the HTTP::DAV module of any use? I just ran across it in TPJ. http://theoryx5.uwinnipeg.ca/CPAN/data/HTTP-DAV/DAV.html Aaron Joao Pedro Goncalves wrote: Hi, is there any current project going on for using the WebDAV protocol in mod_perl, something like Apache::WebDAV? I am familiar with the mod_dav efforts however they seem to be oriented to filesystem repositories and i would like to use WebDAV in a more dynamic environment such as repositories being in a database, or for supporting new stuff like Outlook HTTPmail, that uses WebDAV to connect to Hotmail. If not, is there any people out there interested in starting one? Core features of the WebDAV protocol already have several CPAN modules that would help its development, such as locking and XML processing. Thanks in advance, Joao Pedro -- João Pedro Gonçalves www.sapo.pt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: no such file or directory
Actucally 'file' has always been '/full/path/to/file' because my path in most of my scripts are empty and I have the taintcheck on. Besides they were working under mod_perl for a full week. It's weird that I can now make them work by converting every dbmopen to tie. It seems that perl suddenly decides not to like dbmopen function any more. This function still works for other scripts not running as httpd though. On Thu, Nov 30, 2000 at 07:45:45AM +, G.W. Haywood wrote: Hi there, On Wed, 29 Nov 2000 [EMAIL PROTECTED] wrote: I have this mysterious problem of my mod_perl scripts giving errors like no such file or directory when I know for a fact that files and directory are there. dbmopen %A,'file',0644 Try dbmopen %A,'/full/path/to/file',0644 73, Ged. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Apache::Session Question
I have read all the documentation I can find, but have not found a clear answer about Apache::Session sharing information across load balanced machines? My assumption is that if I am using a database (Oracle), that the information will be available across the load balanced machines. But when I look at the schema for the database, I no longer get the feeling that it is? Can anyone confirm this for me please? -- C Wayne Huling [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: Apache::Carp - Error Handling under mod_perl
Sure. I have attached Apache/Carp.pm, so you can examine it. Some of the main differences that can't be implemented easily under CGI are: * Apache::Carp can be configured in the httpd.conf file to send an e-mail to the server admin by setting 'PerlSetVar APACHE_CARP_HANDLER email'. This way you can easily configure e-mail error notices on production servers and displayed error notices on development servers, _without_ changing Perl code base. This is very useful when you have production and development servers running off of the same CVS tree. * It displays the Apache handler that the error occurred under by using $r-current_callback Some other features that make it different from CGI::Carp include: * Can send e-mail notices - very useful for production servers. * Displays complete call stack even for warns and dies. * Displays user, host, remote_host, and referer (useful for email notices) On Thu, 30 Nov 2000, Gunther Birznieks wrote: Can you help by explaining what this does that is different from CGI::Carp? What are you doing that is Apache specific? Could CGI::Carp do the job? If there was something you needed added to CGI::Carp, would it make sense for you to add the apache-specific function flag to CGI::Carp instead of making a brand-new module? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: Apache::Carp - Error Handling under mod_perl
I forgot to include the Apache/Carp.pm attachment in my last e-mail.
Here it is.
package Apache::Carp;
# $Id: $
use integer;
use strict;
use Mail::Mailer;
# trap die and warn
$main::SIG{__WARN__} = \Apache::Carp::warn;
$main::SIG{__DIE__} = \Apache::Carp::die;
$Apache::Carp::in_use = 'yes';
sub errorMessage {
return if $Apache::Carp::in_use eq 'no';
my $r = Apache-request;
my $s = Apache-server;
return unless $r;
if($r-dir_config('APACHE_CARP_HANDLER') eq 'email'){
my $uri = (split(' ',$r-the_request))[1];
$uri .= '?' . $r-notes('query_string') if $uri !~ /\?/;
my $userID = $r-connection-user;
my $host = $r-header_in('Host');
my $remote_host = $r-header_in('X-Forwarded-For') || $r-get_remote_host;
my $referer = $r-header_in('Referer');
my $current_callback = $r-current_callback;
my $message = END;
$uri
userID: $userID host: $host remote_host: $remote_host referer: $referer
handler: $current_callback
$_[0]
END
my $i = 0;
while (my ($package, $filename, $line, $subr) = caller($i)){
$message .= "stack $i: $package $subr line $line\n";
$i++;
}
my $mailer = new Mail::Mailer;
$mailer-open({To = $s-server_admin,
Subject = "Website $_[1]"
});
print $mailer $message;
$mailer-close;
} elsif ($r-dir_config('APACHE_CARP_HANDLER') eq 'display') {
my $color = $_[1] eq 'WARN' ? 'blue' : 'red';
my $message = $_[0];
$message =~ s//lt;/g;
$message =~ s//gt;/g;
print qq{prefont color="$color"$_[1]: $message};
my $i = 0;
while (my ($package, $filename, $line, $subr) = caller($i)){
print "stack $i: $package $subr line $line\n";
$i++;
}
print qq{/font/prebr};
}
}
sub warn {
errorMessage($_[0],"WARN");
}
sub die {
errorMessage($_[0],"FATAL");
}
1;
__END__
=head1 NAME
Apache::Carp - Error Handling under mod_perl
=head1 SYNOPSIS
In your perl code or Cstartup.pl file:
use Apache::Carp;
In your Apache configuration file:
PerlSetVar APACHE_CARP_HANDLER email
=head1 DESCRIPTION
Redirects warnings and fatal errors to screen or e-mail by using
C__WARN__ and C__DIE__ signal handlers. Includes detailed information
including error message, call stack, uri, host, remote host, remote user,
referrer, and handler.
If CAPACHE_CARP_HANDLER is set to Idisplay, errors will be
displayed on the screen for easy debugging. This should be used in a development
environment only.
If CAPACHE_CARP_HANDLER is set to Iemail, errors will be e-mailed to the site
adminstrator as specified in the Apache CServerAdmin configuration directive.
This should be used on a production site.
=head1 AUTHOR
T.J. Mather ([EMAIL PROTECTED])
=head1 COPYRIGHT
Copyright (c) 2000, AnIdea Corporation. All rights Reserved.
=head1 LICENSE
This program is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY;
without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
See the Ricoh Source Code Public License for more details.
You can redistribute this module and/or modify it only under the terms of the Ricoh
Source Code Public License.
You should have received a copy of the Ricoh Source Code Public License along with
this program; if not, obtain one at http://www.pagekit.org/license
=cut
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wanted: Modperl/Mason consultant:
"cliff" == cliff rayman [EMAIL PROTECTED] writes: cliff plus, everyone knows your bid. cliff i don't have quite the credentials as Ask, but i only cliff cost $119.50 per hour. :-)) I don't either, so I'll bid $119 an hour, but you have to think intensely kind thoughts about me the entire time, and I get to bill for twice as many hours as I actually work, just like some lawyers do. :-) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Apache::Session Question
Apache::Session uses a cookie to identify a user. Every request will be switched to one of the nodes in your cluster. That node will fetch the session data corresponding to that cookie and work with it. Mind you, Apache::Session is a great piece of software, but in balanced envs you may need to balance your session data over multiple database. Then you need some logic to make requests sticky. Hope this helps, Renzo -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: donderdag 30 november 2000 16:07 To: [EMAIL PROTECTED] Subject: Apache::Session Question I have read all the documentation I can find, but have not found a clear answer about Apache::Session sharing information across load balanced machines? My assumption is that if I am using a database (Oracle), that the information will be available across the load balanced machines. But when I look at the schema for the database, I no longer get the feeling that it is? Can anyone confirm this for me please? -- C Wayne Huling [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
More Speed - mod_perl Module for HTML Compression
Hi, I'm trying to reduce the amount of data sent from server to browser by using compression --- hopefully accelerating the time to serve a page. Does anyone know of a mod_perl module that compresses HTML and a companion Javascript procedure that decompresses the data on the client-side? I know there are Gzip modules that zip files on the way back to the browser ... but I'm after something that zips on the server and decompresses transparently in Javascript across all browsers. Ideally I want to do: document.write(uncompressed-contents) in Javascript on the client-side. Has anyone come up with something for this? Also for average-sized files, does the time taken to perform the decompression/compression negate any speed increase gained by reduced file size? Nige Nigel Hamilton __ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More Speed - mod_perl Module for HTML Compression
At 18:14 30/11/2000 +, Nigel Hamilton wrote: Also for average-sized files, does the time taken to perform the decompression/compression negate any speed increase gained by reduced file size? I don't have numbers to back this, but I'm ready to bet that writing an uncompression algo meant to run within a browser is going to be *slow*. Why do you want to do this ? I can't see any reason for wanting this instead of using gz encoding, which will be faster by much, and is a well proven method of sending large files faster. -- robin b. Learn from your parents mistakes - use birth control. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More Speed - mod_perl Module for HTML Compression
On Thu, 30 Nov 2000, Nigel Hamilton wrote: Hi, I'm trying to reduce the amount of data sent from server to browser by using compression --- hopefully accelerating the time to serve a page. Does anyone know of a mod_perl module that compresses HTML and a companion Javascript procedure that decompresses the data on the client-side? I know there are Gzip modules that zip files on the way back to the browser ... but I'm after something that zips on the server and decompresses transparently in Javascript across all browsers. Ideally I want to do: document.write(uncompressed-contents) in Javascript on the client-side. Has anyone come up with something for this? Nobody here would be mad enough to do this... Is it on an intranet? If not, you'll never get me visiting your site - I don't enable javascript generally. Also for average-sized files, does the time taken to perform the decompression/compression negate any speed increase gained by reduced file size? I don't think so, but it probably depends a huge amount on the size of your pipe and how many pages you're hoping to server. For example, I'm on a 64K pipe, so CPU isn't the limiting factor of what I can serve - the pipe is. So I gzip and can serve more pages. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: More Speed - mod_perl Module for HTML Compression
On Thu, 30 Nov 2000, Geoffrey Young wrote: there's mod_gzip, available from http://www.remotecommunications.com/apache/mod_gzip/ which I've played with and looks pretty good or Apache::Compress, available from CPAN, which also works rather nicely (and is Apache::Filter ready, so you can chain PerlHandlers into it) just beware that not all browsers that claim to accept gzip compression actually do... No its the other way around. Not all browsers that can accept gzip send out Accept-Encoding: gzip. Notably early versions of IE4. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
empty or incomplete page returned
I'm building a web application using mod_perl. Sometimes when I do tests using a slow connection I get empty pages returned. This doesn't happen from the local net. The server used for the test isn't tuned and it has low cpu and ram. Could this be the reason of that bad behaviour ? Returning the content-length field to the browser would solve this ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: More Speed - mod_perl Module for HTML Compression
-Original Message- From: Matt Sergeant [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 30, 2000 2:33 PM To: Geoffrey Young Cc: 'Nigel Hamilton'; mod_perl list Subject: RE: More Speed - mod_perl Module for HTML Compression just beware that not all browsers that claim to accept gzip compression actually do... No its the other way around. Not all browsers that can accept gzip send out Accept-Encoding: gzip. Notably early versions of IE4. I was basing that on discussions on the mod_gzip list and the following (from the mod_gzip code) * 5. Many browsers ( such as Netscape 4.75 for UNIX ) are unable *to handle Content-encoding only for specific kinds of HTML *transactions such as Style Sheets even though the browser *says it is HTTP 1.1 compliant and is suppying the standard *'Accept-encoding: gzip' field. According to the IETF *specifications any user-agent that says it can accept *encodings should be able to do so for all types of HTML *transactions but this is simply not the current reality. *Some will, some won't... even if they say they can. I don't have any first hand experience with it, though... --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
mod_perl 1.24 for Apache 1.3.14 patch
Hello colleagues,
In Apache 1.3.14, there is another change in version strings in httpd.h
Here is small patch (quick'n'dirty, of course :) to fix this.
diff -u -r mod_perl-1.24.orig/Makefile.PL mod_perl-1.24/Makefile.PL
--- mod_perl-1.24.orig/Makefile.PL Mon May 15 04:07:58 2000
+++ mod_perl-1.24/Makefile.PL Thu Nov 30 20:13:26 2000
@@ -1497,6 +1497,9 @@
while($fh) {
next unless /^#define/;
s/SERVER_PRODUCT \"/\"Apache/; #1.3.13+
+ #1.3.14 hack
+ $_ = "#define SERVER_VERSION \"Apache/$1\"" if
+ /^#define\s+SERVER_BASEREVISION\s+"(.*)"/;
next unless s/^#define\s+SERVER_(BASE|)VERSION\s+"(.*)\s*".*/$2/;
chomp($string = $_);
diff -u -r mod_perl-1.24.orig/lib/Apache/src.pm mod_perl-1.24/lib/Apache/src.pm
--- mod_perl-1.24.orig/lib/Apache/src.pmFri Mar 31 23:05:24 2000
+++ mod_perl-1.24/lib/Apache/src.pm Thu Nov 30 20:15:10 2000
@@ -213,6 +213,9 @@
while($fh) {
next unless /^#define/;
s/SERVER_PRODUCT \"/\"Apache/; #1.3.13+
+ #1.3.14 hack
+ $_ = "#define SERVER_VERSION \"Apache/$1\"" if
+ /^#define\s+SERVER_BASEREVISION\s+"(.*)"/;
next unless s/^#define\s+SERVER_(BASE|)VERSION\s+"(.*)\s*".*/$2/;
chomp($string = $_);
Sincerely,
D.Marck [DM5020, DM268-RIPE, DM3-RIPN]
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] ***
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: More Speed - mod_perl Module for HTML Compression
On Thu, 30 Nov 2000, Geoffrey Young wrote: just beware that not all browsers that claim to accept gzip compression actually do... No its the other way around. Not all browsers that can accept gzip send out Accept-Encoding: gzip. Notably early versions of IE4. I was basing that on discussions on the mod_gzip list and the following (from the mod_gzip code) * 5. Many browsers ( such as Netscape 4.75 for UNIX ) are unable *to handle Content-encoding only for specific kinds of HTML *transactions such as Style Sheets even though the browser *says it is HTTP 1.1 compliant and is suppying the standard *'Accept-encoding: gzip' field. According to the IETF *specifications any user-agent that says it can accept *encodings should be able to do so for all types of HTML *transactions but this is simply not the current reality. *Some will, some won't... even if they say they can. I don't have any first hand experience with it, though... Yikes, thats really dumb. I guess its both ways around then... shameless_plug So really your best bet is to just use AxKit, which will compress just your HTML content and won't handle your CSS files or anything else :-) /shameless_plug -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: More Speed - mod_perl Module for HTML Compression
there's mod_gzip, available from http://www.remotecommunications.com/apache/mod_gzip/ which I've played with and looks pretty good or Apache::Compress, available from CPAN, which also works rather nicely (and is Apache::Filter ready, so you can chain PerlHandlers into it) just beware that not all browsers that claim to accept gzip compression actually do... geoff - is there any documentation as to which browsers will or will not handle gzip compression? thanks. virginia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: More Speed - mod_perl Module for HTML Compression
-Original Message- From: Wiswell, Virginia [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 30, 2000 2:52 PM To: 'Geoffrey Young'; 'Nigel Hamilton'; mod_perl list Subject: RE: More Speed - mod_perl Module for HTML Compression there's mod_gzip, available from http://www.remotecommunications.com/apache/mod_gzip/ which I've played with and looks pretty good or Apache::Compress, available from CPAN, which also works rather nicely (and is Apache::Filter ready, so you can chain PerlHandlers into it) just beware that not all browsers that claim to accept gzip compression actually do... geoff - is there any documentation as to which browsers will or will not handle gzip compression? I don't think so - from lurking around mod_gzip, I think the folks at Remote Communications have a pretty good grip on what _really_ accepts compression and what doesn't (or so I've gathered), but I don't think it's documented anywhere authoritative (that I know about, at least) a look at the mod_gzip code (http://12.17.228.52/mod_gzip/src/1.3.14.3/mod_gzip.txt search for 'Basic sanity checks completed and we are still here') lists lots of Accept-Encoding problems, but only mention Nescape 4.75 on unix by name... HTH --Geoff thanks. virginia - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More Speed - mod_perl Module for HTML Compression
Nigel Hamilton wrote: Does anyone know of a mod_perl module that compresses HTML and a companion Javascript procedure that decompresses the data on the client-side? I know there are Gzip modules that zip files on the way back to the browser ... but I'm after something that zips on the server and decompresses transparently in Javascript across all browsers. Ideally I want to do: document.write(uncompressed-contents) in Javascript on the client-side. To add to Matt's comments and likely Ged would agree, you'll probably find that Gzip compression is better supported cross browser than any JavaScript you could come up with. JavaScript breaks in lots of ways all the time if you just look at IE4-IE5, NS4.0x-NS4.7x. And then look at them on NT/2000 vs. 95/98/ME, that'll really kill ya. --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks free web link monitoring Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More Speed - mod_perl Module for HTML Compression
"Matt Sergeant" [EMAIL PROTECTED] wrote: On Thu, 30 Nov 2000, Geoffrey Young wrote: just beware that not all browsers that claim to accept gzip compression actually do... No its the other way around. Not all browsers that can accept gzip send out Accept-Encoding: gzip. Notably early versions of IE4. Right, and in response to Nigel's assumtion: ...I'm after something that zips on the server and decompresses transparently in Javascript across all browsers. I believe you'd find that a lot more browsers will already transparently decompress your server-gzipped content for you, than you will JavaScript-enabled browsers that will successfully decompress the content for you. Another reason being that you can *detect* Accept-Encoding: gzip in a browser's request headers (and even workaround the IE versions that dont send this by looking at their USER_AGENT headers) and know beforehand whether gzipped content can be decoded by that browser or not, while there are no such early-warning systems to assure you that Javascript will be enabled. So, since most modern browsers *already* decompress gzip on the fly, why would you want to add all the necessary JS code (to the content-size) and then ask the JavaScript interpreter to do what the browser already knows how to do? -dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: More Speed - mod_perl Module for HTML Compression
Hi all, On Thu, 30 Nov 2000, an assortment of correspondents wrote: beware that not all browsers that claim to accept gzip compression actually do... No its the other way around. Not all browsers that can accept gzip send out Accept-Encoding: gzip. Notably early versions of IE4. I was basing that on discussions on the mod_gzip list and the following I think it's safe to say that most browsers (mentioning no two in particular:) do exactly what they're supposed to do very rarely. Especially if JavaScript is involved. 73, Ged. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl 1.24 for Apache 1.3.14 patch
Not long ago, Dmitry Morozovsky proclaimed... Hello colleagues, In Apache 1.3.14, there is another change in version strings in httpd.h Here is small patch (quick'n'dirty, of course :) to fix this. I noticed this too. I'm not sure, but I think this affected 1.3.13 too, but I could be wrong. Is the "proper" fix a change to Apache's code or mod_perl's Makefile.PL? I'm guessing since mod_perl is an "add-on" to Apache, fixing mod_perl's configuration script to recognize the new version strings is the most appropriate fix. Think 1.25 will have this fixed? -=Fozz (still running 1.3.12 for now) -- Doran L. Barton [EMAIL PROTECTED] - Chief Super Hero - Iodynamics LLC http://www.iodynamics.com/ - Linux solutions and dynamic websites "A good messenger expects to get shot." --- Larry Wall - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: empty or incomplete page returned
Hi there, On Thu, 30 Nov 2000, Francesc Guasch wrote: I'm building a web application using mod_perl. Sometimes when I do tests using a slow connection I get empty pages returned. This doesn't happen from the local net. Do your logs shed any light? The server used for the test isn't tuned and it has low cpu and ram. Could this be the reason of that bad behaviour ? Don't think so, unless you're getting segfaults in the logs or something. Could you give just a little more information...? Returning the content-length field to the browser would solve this ? Don't think so. 73, Ged. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: [OT] More Speed - mod_perl Module for HTML Compression
Hi there, On Thu, 30 Nov 2000, Wiswell, Virginia wrote: geoff - is there any documentation as to which browsers will or will not handle gzip compression? Sorry to chime in again, I think we're way OT, but I'd say don't do it unless you have complete control over your browser situation. If you have complete control over your browser situation you'll be the first one I've met. And it won't last, that I can promise you. 73, Ged. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: empty or incomplete page returned
On Thu, 30 Nov 2000, Francesc Guasch wrote: I'm building a web application using mod_perl. Sometimes when I do tests using a slow connection I get empty pages returned. This doesn't happen from the local net. The server used for the test isn't tuned and it has low cpu and ram. Could this be the reason of that bad behaviour ? Returning the content-length field to the browser would solve this ? You are either having some kind of error on the server (check the error_log) or the connection is timing out. - Perrin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mime-type headers
"EG" == Eustace, Glen [EMAIL PROTECTED] writes: EG But with IE, no go. I have 2 PCs, both with IE5.5 and with acrobat 4 and the EG other acrobat 3. On the first, on both I get no new window, a page of EG hieroglyphics on the first and on the second I get acrobat started but no EG page displayed. You see, IE is smarter than the web site authors of the world. It insists that the document URL end in an approprate extension to do the right thing. A typical workaround is to just append "/foo.pdf" to your URL and let your Apache::Registry script ignore the PATH_INFO that is the result of that. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More Speed - mod_perl Module for HTML Compression
[EMAIL PROTECTED] (Nigel Hamilton) wrote: I'm trying to reduce the amount of data sent from server to browser by using compression --- hopefully accelerating the time to serve a page. Does anyone know of a mod_perl module that compresses HTML and a companion Javascript procedure that decompresses the data on the client-side? I know there are Gzip modules that zip files on the way back to the browser ... but I'm after something that zips on the server and decompresses transparently in Javascript across all browsers. Ideally I want to do: document.write(uncompressed-contents) in Javascript on the client-side. I think you've got a slight misconception about how gzip HTTP compression works. It's perfectly transparent, in that browsers that support compression will decompress the file automatically, and the user will never know that the page was compressed in the first place. That's much smoother than the javascript decompression you propose, which I can't help thinking will turn into a real headache, perhaps even a nightmare. In particular, it seems like you think that users have to manually decompress gzipped content, but that's not the case. Just thought I'd state it if that was the confusion. mod_gzip, Apache::Compress, or Apache::Gzip are solutions here. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mime-type headers
You see, IE is smarter than the web site authors of the world. It insists that the document URL end in an approprate extension to do the right thing. A typical workaround is to just append "/foo.pdf" to your URL and let your Apache::Registry script ignore the PATH_INFO that is the result of that. Thanks, I though it was going to be something STUPID, like this. Is there a header I can use that will tell IE another file name 'FIlename: xxx.pdf' or something? -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Vivek Khera, Ph.D.Khera Communications, Inc. Internet: [EMAIL PROTECTED] Rockville, MD +1-240-453-8497 AIM: vivekkhera Y!: vivek_khera http://www.khera.org/~vivek/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl 1.24 for Apache 1.3.14 patch
On Thu, 30 Nov 2000, Doran L. Barton wrote: DLB Not long ago, Dmitry Morozovsky proclaimed... DLB Hello colleagues, DLB DLB In Apache 1.3.14, there is another change in version strings in httpd.h DLB Here is small patch (quick'n'dirty, of course :) to fix this. DLB DLB I noticed this too. I'm not sure, but I think this affected 1.3.13 too, but DLB I could be wrong. Is the "proper" fix a change to Apache's code or DLB mod_perl's Makefile.PL? One line above my patch you can find remark "#1.3.13+". Unluckily enough, the '+' sign is not in a proper place ;-) The second file in patch is src.pm, which parse Apache configs and contains exactly the same sub. DLB I'm guessing since mod_perl is an "add-on" to Apache, fixing mod_perl's DLB configuration script to recognize the new version strings is the most DLB appropriate fix. So there is the places I patched, you see ;-) Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_perl 1.24 for Apache 1.3.14 patch
On Nov 30, Doran L. Barton wrote: [ patch to handle 1.3.14 version string ] Think 1.25 will have this fixed? its already fixed in 1.24_01(*), so yes. jim (*) http://perl.apache.org/dist/mod_perl-1.24_01.tar.gz - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mime-type headers
It's been my experience that IE will ignore the sent content-type when it thinks it knows what to do by the file extension. So, if the request is say, .html which happens to be dynamic with respect to your server and may return another content-type, IE will try to display it as html anyway. You should be able to use an unknown (to IE) extension and return the desired content-type for the appropriate action by the client (but that's not necessarily guaranteed). The simplest solution may be to make sure that you're requesting or redirecting to a .pdf file for IE. This would actually be much simpler if you were using custom content handlers rather than Apache::Registry. Thanks, Tim Tompkins -- Staff Engineer / Programmer http://www.arttoday.com/ -- - Original Message - From: "Eustace, Glen" [EMAIL PROTECTED] To: "Mod-Perl Mailing List (E-mail)" [EMAIL PROTECTED] Sent: Thursday, November 30, 2000 1:02 PM Subject: mime-type headers This isn't strictly a mod_perl issue but Im hoping someone knows what I am doing wrong. The code is running under Apache::Registry I have a series of invoices, stored as postscript files. I have a page which allows the client to select a file. I then run it through 'gs' and convert it to a PDF using open(). prior to reading the pipe and spitting the data to the browser, I have output the headers 'content-type: application/pdf' and 'window-target: Invoice'. The result is as expected with netscape, on Win32 I get a new window and netscape has started Acrobat and displays the invoice in the new window. On linux, netscape starts a new window but fires up xpdf to actually show the page. All in all it works pretty well. But with IE, no go. I have 2 PCs, both with IE5.5 and with acrobat 4 and the other acrobat 3. On the first, on both I get no new window, a page of hieroglyphics on the first and on the second I get acrobat started but no page displayed. Any clues ? -- Glen Eustace, Systems Engineer - Networking. Information Technology Services, Turitea, Massey University, Palmerston North, NZ. Ph: +64 6 350 5799 x 2707, Fax: +64 6 350 5607 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: More Speed - mod_perl Module for HTML Compression
"Ken" == Ken Williams [EMAIL PROTECTED] writes: Ken In particular, it seems like you think that users have to manually Ken decompress gzipped content, but that's not the case. Just thought I'd Ken state it if that was the confusion. Ken mod_gzip, Apache::Compress, or Apache::Gzip are solutions here. Or even my cool compressing pre-forking tiny proxy at http://www.stonehenge.com/merlyn/WebTechniques/col34.html Neatly proxies, but sends compressed text across slow links if the browser understands that. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mime-type headers
At 10:44 AM 12/1/00 +1300, Eustace, Glen wrote: You see, IE is smarter than the web site authors of the world. It insists that the document URL end in an approprate extension to do the right thing. A typical workaround is to just append "/foo.pdf" to your URL and let your Apache::Registry script ignore the PATH_INFO that is the result of that. Thanks, I though it was going to be something STUPID, like this. Is there a header I can use that will tell IE another file name 'FIlename: xxx.pdf' or something? I've found ?.pdf to work just as well to fool IE and your artificially created PATH_INFO filename will then stick if a user does a save as. BTW, I think your problem may occur only on IE and W2k (even with IE 5 not 5.5). If you use IE and Win98 you won't have the same extension problem. At least I didn't. There is an attachment header you can give, but that's used for sending a file for download I believe-- a kind of forced save as which you may not want. Later, Gunther - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Apache::Session Question
At 05:17 PM 11/30/00 +0100, Renzo Toma wrote: Apache::Session uses a cookie to identify a user. Every request will be This is an accurate reply to the message but... I think you want to be careful with terminoloy. Apache::Session does not use a BROWSER level cookie. I think you are using the word cookie to mean session id/handle. But it's may be a bit confusing to read your message because the word cookie is so overloaded to mean browser cookie. switched to one of the nodes in your cluster. That node will fetch the session data corresponding to that cookie and work with it. Mind you, Apache::Session is a great piece of software, but in balanced envs you may need to balance your session data over multiple database. Then you need some logic to make requests sticky. Hope this helps, Renzo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mime-type headers
I've found ?.pdf to work just as well to fool IE and your artificially created PATH_INFO filename will then stick if a user does a save as. This is an absolute crock, but it works a treat. I now have form action="AcctMgmt.epl?.pdf" method=post" Thanks. Glen. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: More Speed - mod_perl Module for HTML Compression
Actually its both then. I've had to hack up mod_gzip to not send compressed data if the following is true: 1. The browser is Netscape 2. The URL is a javascript file (ends in .js). Netscape sends Accept-Encoding: gzip for javascript files and then doesn't know what to do with them. -Paul -Original Message- From: Matt Sergeant [mailto:[EMAIL PROTECTED]] Sent: Thursday, November 30, 2000 2:33 PM To: Geoffrey Young Cc: 'Nigel Hamilton'; mod_perl list Subject: RE: More Speed - mod_perl Module for HTML Compression On Thu, 30 Nov 2000, Geoffrey Young wrote: there's mod_gzip, available from http://www.remotecommunications.com/apache/mod_gzip/ which I've played with and looks pretty good or Apache::Compress, available from CPAN, which also works rather nicely (and is Apache::Filter ready, so you can chain PerlHandlers into it) just beware that not all browsers that claim to accept gzip compression actually do... No its the other way around. Not all browsers that can accept gzip send out Accept-Encoding: gzip. Notably early versions of IE4. -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mime-type headers
Thanks, I though it was going to be something STUPID, like this. Is there a header I can use that will tell IE another file name 'FIlename: xxx.pdf' or something? You can try: Content-Disposition: attachment; filename=somefile.pdf Or I think even this may work: Content-Disposition: inline; filename=somefile.pdf Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: mime-type headers
Or I think even this may work: Content-Disposition: inline; filename=somefile.pdf This works too. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mime-type headers
Eustace, Glen wrote: But with IE, no go. I have 2 PCs, both with IE5.5 and with acrobat 4 and the other acrobat 3. On the first, on both I get no new window, a page of hieroglyphics on the first and on the second I get acrobat started but no page displayed. Any clues ? Some time ago I had this problem with "Window-Target", too. I wanted to use it for an elegant solution for a customer - automatic choice of the target frame depending on content etc. At last I removed all related code and developed a complete other solution independent of "Window- Target", because it is working ONLY with Netscape-Browsers and NOT with M$-IE5! Unfortunately most of the surfers (according to our webstats) are using M$-IE5 - so forget "Window-Target"... Ernest -- Yours sincerely Mit freundlichen Grüßen Ernest Lergon VIRTUALITAS Artists online, Fine Arts online, Poets online http://www.virtualitas.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antwort: RFC: DBI::Prof
On Thu, 30 Nov 2000 [EMAIL PROTECTED] wrote: Hi, I'm not quite sure, but I think the following would produce wrong results, wouldn't it? $sth1 = $dbh-prepare(...); $sth2 = $dbh-prepare(...); $sth1-execute(); $sth3 = $dbh-prepare(...); $sth2-execute(); $sth3-execute(); That's correct. So it's kinda disqualifies my hack to be placed on CPAN. At this moment I don't have the tuits to make it a non-hack and work for everybody, so I'll just leave it as it is in mod-perl list archive. May be I'll put it into the guide... It would be much easier for Tim to do it from the inside than any of us doing the overloading hacking, but that's up to Tim to decide when if ever this should go in :) Michael Jacob Datum: 28.11.2000 21:12 An:mod_perl list [EMAIL PROTECTED] Betreff: RFC: DBI::Prof Nachrichtentext: I have a huge project with lots of tables, and the performance wasn't that well. So I've started to review the tables definitions and have found that some indices were missing. I was sick from doing the tracing of all possible SQL calls manually, so I wrote this simple profiler. Take a look and tell me if you think it worths releasing on CPAN... hmm, why mod_perl list... because it works under mod_perl :) In fact I didn't test it under non mod_perl but it should work as well :) Anyway, enjoy :) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: Apache::Carp - Error Handling under mod_perl
OK, I can see the advantage of the Apache specific stuff. However, in looking at your code, I think you may not be taking into account a lot of eval logic that CGI::Carp has. Eval logic is the hardest to get right (and I bet there are still bugs) because SIG die is still called within an eval. But some evals are "OK" -- for example Apache::Registry scripts are essentially the result of evaling. Also, you don't appear to be catching croak, carp, and confess. It's not necessarily obvious if you really want a full stack trace for all dies. It usually makes sense for the programmer to choose the stack trace method. These things are taken care of in CGI::Carp. However, with that said, I think your code could make use of CGI::Carp and wrap around it with similar effect. As for sending email... You do know that there is a variable in CGI::Carp where you can set up a reference to a subroutine instead of using Lincoln Stein's right? This can be set up to email instead of or in conjunction with printing to the display. Anyway, I do think the Apache side is useful, but I question rewriting the logic of CGI::Carp when it looks like you could be making use of it as either a subclass or a containment. At 11:08 AM 11/30/00 -0500, Thomas J. Mather wrote: Sure. I have attached Apache/Carp.pm, so you can examine it. Some of the main differences that can't be implemented easily under CGI are: * Apache::Carp can be configured in the httpd.conf file to send an e-mail to the server admin by setting 'PerlSetVar APACHE_CARP_HANDLER email'. This way you can easily configure e-mail error notices on production servers and displayed error notices on development servers, _without_ changing Perl code base. This is very useful when you have production and development servers running off of the same CVS tree. * It displays the Apache handler that the error occurred under by using $r-current_callback Some other features that make it different from CGI::Carp include: * Can send e-mail notices - very useful for production servers. * Displays complete call stack even for warns and dies. * Displays user, host, remote_host, and referer (useful for email notices) On Thu, 30 Nov 2000, Gunther Birznieks wrote: Can you help by explaining what this does that is different from CGI::Carp? What are you doing that is Apache specific? Could CGI::Carp do the job? If there was something you needed added to CGI::Carp, would it make sense for you to add the apache-specific function flag to CGI::Carp instead of making a brand-new module? __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
WANTED: mod_perl consulting work
While my new company is busy acquiring investment money so we can develop or real product I'm looking for some short term mod_perl consulting work to help fund the company. Preferably the work will be telecommuting or in the Austin, TX area. A brief synopsis of my qualifications: 5 years of Perl programming 3 years of mod_perl programming 3 years of Embperl programming Authored three Apache/mod_perl modules (Apache::AuthenCache, Apache::DBILogConfig, Apache::ProxyStuff) Lead web developer at www.Austin360.com (1996-1998) Senior Engineer/Team Lead at Tivoli Systems (1998-2000) Senior Engineer/Researcher at TeamLinux (2000) So, if you need any Perl/mod_perl/Embperl development work drop me a line and will work something out. Thanks. -- Jason Bodnar [EMAIL PROTECTED] Gocho Networks Homer: I don't want you to see me sitting on my worthless butt. Bart: We've seen it, Dad. Homer at the Bat - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: Apache::Carp - Error Handling under mod_perl
OK, I think Apache::Carp was a misleading name - it is not really a replacement for CGI::Carp - instead it is a simple module for reporting errors under a mod_perl enviroment that is easy to use and doesn't require that the programmer use carp and croak. A better name would have been something like Apache::ErrorReport So, I think I will keep this bundled with the Apache-PageKit distribution as Apache::PageKit::Error, (although it will still work by itself), unless there is demand for a seperate Apache-ErrorReport distribution. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: Apache::Carp - Error Handling under mod_perl
I didn't mean for you to withdraw. I would encourage you to still make it Apache::Carp. But then to avoid confusion model it more after CGI::Carp while adding the features you wanted for Apache::PageKit. As a person who has hacked and debugged the internals of CGI::Carp and looking at your code, I think it is entirely doable for this to happen. As a user of CGI::Carp, I'd certainly like to see an Apache::Carp facility. As for not requiring the programmer to use croak and carp. To some degree I agree that it may be nice to override die with a stack traced die. But I know that when I program modules and applications I take special care to use croak, die, and confess in the different situations they were intended for. Anyway, you could offer both the stack traced die and the croak/confess/carp compatibility in the same fell swoop but just offer it as a config option. The other thing that worries me is that even if you sneak the code back into the PageKit hierarchy you are still not doing everything Lincoln is doing to help deal with eval issues. This is a particularly thorny problem (and I suspect part of the reason why Matt wants CGI::Carp to die ... no pun intended). You may not have experienced this problem because your PageKit hasn't run on top of so many different people's scripts and programming styles. CGI::Carp runs on a LOT of platforms and programming styles, so it's evolved to take care of them which you could/should be taking advantage of IMHO while still providing a benefit to the Apache community. Later, Gunther At 11:37 PM 11/30/2000 -0500, Thomas J. Mather wrote: OK, I think Apache::Carp was a misleading name - it is not really a replacement for CGI::Carp - instead it is a simple module for reporting errors under a mod_perl enviroment that is easy to use and doesn't require that the programmer use carp and croak. A better name would have been something like Apache::ErrorReport So, I think I will keep this bundled with the Apache-PageKit distribution as Apache::PageKit::Error, (although it will still work by itself), unless there is demand for a seperate Apache-ErrorReport distribution. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Web Technology Company http://www.extropia.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: RFC: Apache::Carp - Error Handling under mod_perl
Yes it would be useful to have an Apache::Carp as Gunther described it, but I don't really have the time right now to develop it. Maybe I'll get the time to later, but in the meanwhile, I'll stick with the current module in PageKit (it works well with code written under PageKit). If anybody else wants to take up the torch that would be great. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Accelerated apache
Has anyone here try compiling mod_perl with apache patched with this: http://oss.sgi.com/projects/apache/ ? Either 1.3.12 or 1.3.14 stucked at : Connection.xs: In function `XS_Apache__Connection_remote_ip': Connection.xs:107: incompatible types in assignment make[5]: *** [Connection.o] Error 1 make[4]: *** [all] Error 1 Rgds, Edwin. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
