Re: ASP.NET Linux equivalent?
Medi Montaseri [EMAIL PROTECTED] writes: You can also use the tie() feature of Perl to abstract read/write to database. In fact you can write a pretty flexible module to figure out many things, such as table name, col name, etc... I'm a HUGE fan of Tie::DBI for dealing with little lookup tables. Works especially well with GGI.pm's widgets for creating drop downs and radio lists. Whatever happened to the widget subproject that span out of the modperl list a few months ago? -- David Hodgkinson, Wizard for Hirehttp://www.davehodgkinson.com Editor-in-chief, The Highway Star http://www.deep-purple.com Deep Purple Family Tree news http://www.slashrock.com Interim Technical Director, Web Architecture Consultant for hire
ANNOUNCE: Log::Dispatch::Config 0.04
Log::Dispatch::Config provides a way to configure Log::Dispatch with AppConfig style config file format. newest version 0.04 has done whole architecture redesign (subclassing, kickout messy closure), and now is on its way to CPAN. 0.04 Thu Dec 6 18:33:50 JST 2001 * --- API change (with backward compatibility) --- Whole architecture redesign: now inherits from Log::Dispatch. The URL http://bulknews.net/lib/archives/Log-Dispatch-Config-0.04.tar.gz has entered CPAN as file: $CPAN/authors/id/M/MI/MIYAGAWA/Log-Dispatch-Config-0.04.tar.gz size: 5435 bytes md5: ae6fdb0caf61641ba35a622235b9f0d2
Re: ANNOUNCE: Log::Dispatch::Config 0.04
0.04 has a problem in Makefile.PL (CVS replaces $Log: with his RCS keyword, Crap!). Now 0.05 is uploaded or can be fetched from: http://bulknews.net/lib/archives/Log-Dispatch-Config-0.05.tar.gz On Thu, 06 Dec 2001 19:01:34 +0900 Tatsuhiko Miyagawa [EMAIL PROTECTED] wrote: Log::Dispatch::Config provides a way to configure Log::Dispatch with AppConfig style config file format. newest version 0.04 has done whole architecture redesign (subclassing, kickout messy closure), and now is on its way to CPAN. 0.04 Thu Dec 6 18:33:50 JST 2001 * --- API change (with backward compatibility) --- Whole architecture redesign: now inherits from Log::Dispatch. -- Tatsuhiko Miyagawa [EMAIL PROTECTED]
have a memory leaking
Hello All,
I have a problem with configuring Apache from mod_perl.
Descriptions of all virtual host i've got from MySQL DB.
And in cycle wrote:
$VirtualHost{$row[0]:80} = {
ServerName = $row[0],
DocumentRoot = $root/www,
ErrorLog = $root/logs/error_log,
CustomLog = $root/logs/access_log combined,
ServerAdmin = '[EMAIL PROTECTED]',
ScriptAlias = {
'/cgi-bin/' = /home/alexis/sd/kuban.com/cgi-bin/,
},
AddHandler = {
'cgi-script' = '.cgi',
},
Directory = {
$root/www = {
Options = 'ExecCGI',
AllowOverride = 'None',
Order = 'deny,allow',
Deny = 'from all',
Allow = 'from 195.161.243.16/255.255.255.240',
SetHandler = 'perl-script',
PerlHandler = 'SD',
PerlSendHeader = 'On',
},
$root/cgi-bin = {
AllowOverride = 'None',
Options = 'ExecCGI',
SetHandler = 'perl-script',
PerlFixupHandler = 'SD::Trans',
PerlHandler = 'SD',
PerlSendHeader = 'On',
},
},
};
And all well (all works!), but when rebooting an apache (apachectl restart) size,
occupied by each process, increases (as a rule on 2Mb).
Where rake, but?
Platform - FreeBSD 4.3-RELEASE
Apache/1.3.20 (Unix) mod_perl/1.26 mod_ssl/2.8.4 OpenSSL/0.9.6 PHP/4.0.6 rus/PL30.5
--
Best regards,
alexis mailto:[EMAIL PROTECTED]
CGI.pm 2.78 and mod_perl 1.26 troubles
Hey gang, I just upgraded the CGI.pm perl module to 2.78 (don't know what the old version was) and now none of my scripts running under Apache::Registry are working. Instead of executing the scripts, I'm prompted to save the script. Here is a sample script: #!/usr/bin/perl use CGI qw/:standard/; print header; #print Content-Type: text/html\n\n; print start_html, h1(Hello, World!), end_html; This works in the regular cgi-bin directory, but not in the directory for the mod_perl scripts. Uncomment the line that manually produces the header and comment out the call to header() and it works fine. I'm also getting the occasional error message in the error_log: [Thu Dec 6 10:41:53 2001] [error] Can't coerce array into hash at (eval 35) line 31. Has anybody else experienced this or have any clue as to what may be going on? Here is the perl section of httpd.conf and relevant stats: Apache 1.3.22 mod_perl 1.26 mod_ssl 2.8.5 httpd.conf: Alias /perl/ /usr/local/apachessl/perl/ Location /perl SetHandlerperl-script PerlHandler Apache::Registry PerlSendHeader On Options +ExecCGI /Location PerlRequire conf/startup.pl PerlFreshRestart On PerlTaintCheck On -David
Re: a new modperl book: mod_perl Developer's Cookbook
Stas Bekman wrote: SAMS will publish the new mod_perl Developer's Cookbook by Geoffrey Young, Paul Lindner and Randy Kobes in January, 2002. You can find more info at http://www.modperlcookbook.org/. Great work guys! thanks for the mention Stas - a bit ahead of schedule but appreciated nonetheless :) we plan on making an official announcement when the book is released. in the meanwhile, we're working on turning some of the more practical book examples into official releases for CPAN. expect some RFCs soon... --Geoff
Creating an installable web site.
Im looking for a way to create an installable version of my wesite to distribute to customers that don't have web access. The site basically shows the inventory I have and uses a postgres database and mod perl to show the product sorted in the manner that the user wants to see it. Can someone point me in the right direction or am I completely out of luck here? Chris
Re: a new modperl book: mod_perl Developer's Cookbook
At 10:56 AM -0500 12/6/01, Geoffrey Young wrote: Stas Bekman wrote: SAMS will publish the new mod_perl Developer's Cookbook by Geoffrey Young, Paul Lindner and Randy Kobes in January, 2002. You can find more info at http://www.modperlcookbook.org/. Great work guys! thanks for the mention Stas - a bit ahead of schedule but appreciated nonetheless :) we plan on making an official announcement when the book is released. in the meanwhile, we're working on turning some of the more practical book examples into official releases for CPAN. expect some RFCs soon... Advance ordered via Amazon.com! Actually I did it awhile ago when I first found out that there was a new mod_perl. Rob -- Only two things are infinite: The universe, and human stupidity. And I'm not sure about the former. --Albert Einstein
Re: a new modperl book: mod_perl Developer's Cookbook
Advance ordered via Amazon.com! Actually I did it awhile ago when I first found out that there was a new mod_perl. cool. BTW, if you do pre-order, following the amazon link from our homepage results in a little extra for us authors (which helps pay for things like domain registration fees and other such stuff that keeps the website up). --Geoff
[RFC] Apache::CacheContent - Caching PerlFixupHandler
Hi,
I would like to propose a new Apache module before I send it off to
CPAN. The name chosen is Apache::CacheContent.
It's pretty generic code, and is intended to be subclassed. It
handles the gory details of caching a page to disk and serving it up
until it expires.
It's derived from work done on the mod_perl Developer's Cookbook, so
it's already been reviewed by a number of people.
I've attached a README below. To download it go to
http://www.modperlcookbook.org/code.html
NAME
Apache::CacheContent - PerlFixupHandler class that caches dynamic
content
SYNOPSIS
* Make your method handler a subclass of Apache::CacheContent
* allow your web server process to write into portions of your document
root.
* Add a ttl() subroutine (optional)
* Add directives to your httpd.conf that are similar to these:
PerlModule MyHandler
# dynamic url
Location /dynamic
SetHandler perl-script
PerlHandler MyHandler-handler
/Location
# cached URL
Location /cached
SetHandler perl-script
PerlFixupHandler MyHandler-disk_cache
PerlSetVar CacheTTL 120 # in minutes...
/Location
DESCRIPTION
Note: This code is derived from the *Cookbook::CacheContent*
module, available as part of The mod_perl Developer's
Cookbook
The Apache::CacheContent module implements a PerlFixupHandler that helps
you to write handlers that can automatically cache generated web pages
to disk. This is a definite performance win for sites that end up
generating the exact same content for many users.
The module is written to use Apache's built-in file handling routines to
efficiently serve data to clients. This means that your code will not
need to worry about HTTP/1.X, byte ranges, if-modified-since, HEAD
requests, etc. It works by writing files into your DocumentRoot, so be
sure that your web server process can write there.
To use this you MUST use mod_perl method handlers. This means that your
version of mod_perl must support method handlers (the argument
EVERYTHING=1 to the mod_perl build will do this). Next you'll need to
have a content-generating mod_perl handler. If isn't a method handler
modify the *handler* subroutine to read:
sub handler ($$) {
my ($class, $r) = @_;
Next, make your handler a subclass of *Apache::CacheContent* by adding
an ISA entry:
@MyHandler::ISA = qw(Apache::CacheContent);
You may need to modify your handler code to only look at the *uri* of
the request. Remember, the cached content is independent of any query
string or form elements.
After this is done, you can activate your handler. To use your handler
in a fully dyamic way configure it as a PerlHandler in your httpd.conf,
like this:
PerlModule MyHandler
Location /dynamic
SetHandler perl-script
PerlHandler MyHandler-handler
/Location
So requests to *http://localhost/dynamic/foo.html* will call your
handler method directly. This is great for debugging and testing the
module. To activate the caching mechanism configure httpd.conf as
follows:
PerlModule MyHandler
Location /cached
SetHandler perl-script
PerlFixupHandler MyHandler-disk_cache
PerlSetVar CacheTTL 120 # in minutes..
/Location
Now when you access URLs like *http://localhost/cached/foo.html* the
content will be generated and stored in the file
*DocumentRoot*/cached/foo.html. Subsequent request for the same URL will
return the cached content, depending on the *CacheTTL* setting.
For further customization you can write your own *ttl* function that can
dynamically change the caching time based on the current request.
AUTHOR
Paul Lindner [EMAIL PROTECTED], Geoffrey Young, Randy Kobes
SEE ALSO
The example mod_perl method handler the CacheWeather manpage.
The mod_perl Developer's Cookbook
--
Paul Lindner [EMAIL PROTECTED]| | | | | | | | | |
mod_perl Developer's Cookbook http://www.modperlcookbook.org
Human Rights Declaration http://www.unhchr.ch/udhr/index.htm
Re: ASP.NET Linux equivalent?
Dave Hodgkinson [EMAIL PROTECTED] said something to this effect on 12/06/2001: Whatever happened to the widget subproject that span out of the modperl list a few months ago? http://www.officevision.com/pub/Widget/ Not too active lately: http://sourceforge.net/project/stats/?group_id=27958 (darren) -- This is the crucial difference between fiction and real life: fiction must be plausible; real life has no such constraint. -- Kevin Kelly
Re: Creating an installable web site.
On Thu, Dec 06, 2001 at 11:01:09AM -0500, Chris Pizzo wrote: Im looking for a way to create an installable version of my wesite to distribute to customers that don't have web access. The site basically shows the inventory I have and uses a postgres database and mod perl to show the product sorted in the manner that the user wants to see it. Can someone point me in the right direction or am I completely out of luck here? Well, depending on your site you have two options: * if the available options for sorting the product are limited, you're best off by saving the resulting pages (wget, etc) on disk. Make sure the links stored are relative to the current dir and that they don't have no characteres that would make them impossible of being stored in vfat/iso9660+joilet+rr/ext2/etc. * have on cd apache with mod_perl and postgresl in installable form with your data. Or have them already installed on the cd. The problem here is that the source for your entire site will have to be distributed too and available for everybody's eyes to see. You'll also have to have different apaches and postgres for every architecture your clients use, and you should configure them to use different ports than the normal ones and above 1024, so that they don't conflict with already running web servers and rdbms. Also, they will have to be configured without absolute paths, and without any creation or writting to files (the cd medium is read-only, of course). Good luck! :) Regards -- Luciano Rocha, [EMAIL PROTECTED] The trouble with computers is that they do what you tell them, not what you want. -- D. Cohen
Re: CGI.pm 2.78 and mod_perl 1.26 troubles
Solved it... apparently, if you upgrade CGI.pm while your web server is running, a restart is not good enough. You have to shutdown completely and then start it back up. *Sigh* -David On Thu, 2001-12-06 at 10:43, David Shrewsbury wrote: Hey gang, I just upgraded the CGI.pm perl module to 2.78 (don't know what the old version was) and now none of my scripts running under Apache::Registry are working. Instead of executing the scripts, I'm prompted to save the script. Here is a sample script: #!/usr/bin/perl use CGI qw/:standard/; print header; #print Content-Type: text/html\n\n; print start_html, h1(Hello, World!), end_html; This works in the regular cgi-bin directory, but not in the directory for the mod_perl scripts. Uncomment the line that manually produces the header and comment out the call to header() and it works fine. I'm also getting the occasional error message in the error_log: [Thu Dec 6 10:41:53 2001] [error] Can't coerce array into hash at (eval 35) line 31. Has anybody else experienced this or have any clue as to what may be going on? Here is the perl section of httpd.conf and relevant stats: Apache 1.3.22 mod_perl 1.26 mod_ssl 2.8.5 httpd.conf: Alias /perl/ /usr/local/apachessl/perl/ Location /perl SetHandlerperl-script PerlHandler Apache::Registry PerlSendHeader On Options +ExecCGI /Location PerlRequire conf/startup.pl PerlFreshRestart On PerlTaintCheck On -David
[ANNOUNCE] OpenFrame 2.06
OpenFrame 2.06 has just been uploaded to CPAN. OpenFrame is a Perl Application framework that coexists nicely with mod_perl. We had lots of helpful feedback from the last release which has been bundled into this one, along with several other improvements. The OpenFrame website is running at http://openframe.fotango.com, where you can find the distribution in between now and the time it takes to perculate through the CPAN mirrors. The changes to OpenFrame follow. Regards, James. CHANGES, 2.06 - removed warning in OpenFrame::Config - more docs: OpenFrame, OpenFrame::Install - complete redesign of OpenFrame::AbstractCookie - new Apache example, which shows OpenFrame being served by Apache and mod_perl - new OpenFrame::Server::SOAP (and example), which allows OpenFrame systems to be accessed over SOAP rather than HTTP - new slots to parse XML documents and perform XSL transforms in OpenFrame::Slot::XML and OpenFrame::Slot::XSLT - new OpenFrame::Server::Zeus (and example) to allow the Zeus web server to serve OpenFrame applications
Re: have a memory leaking
On Thu, Dec 06, 2001 at 04:58:31PM +0300, alexis@kubic wrote: Hello All, I have a problem with configuring Apache from mod_perl. Descriptions of all virtual host i've got from MySQL DB. And in cycle wrote: [snip] And all well (all works!), but when rebooting an apache (apachectl restart) size, occupied by each process, increases (as a rule on 2Mb). Where rake, but? Platform - FreeBSD 4.3-RELEASE Apache/1.3.20 (Unix) mod_perl/1.26 mod_ssl/2.8.4 OpenSSL/0.9.6 PHP/4.0.6 rus/PL30.5 This memory leak on restart is common when Apache is compiled as a DSO. I suggest stopping and starting the server. This command has worked for me in the past. apachectl stop; sleep 1; apachectl start -- Paul Lindner [EMAIL PROTECTED]| | | | | | | | | | mod_perl Developer's Cookbook http://www.modperlcookbook.org Human Rights Declaration http://www.unhchr.ch/udhr/index.htm
Re: [RFC] Apache::CacheContent - Caching PerlFixupHandler
I would like to propose a new Apache module before I send it off to CPAN. The name chosen is Apache::CacheContent. This is very cool. I was planning to write one of these, and now I don't have to. Your implementation is short and interesting. I was planning to do it with a PerlFixupHandler and an Apache::Filter module to capture the output. While that approach wouldn't require the use of method handlers, I think yours may be easier for newbies because it doesn't require them to understand as many modules. The only real advantage of using Apache::Filter is that it would work well with existing Registry scripts. A couple of other C's for your R: A cache defines parameters that constitute a unique request. Your cache currently only handles the filename from the request as a parameter. It would be nice to also handle query args, POST data, and arbitrary headers like cookies or language choices. You could even support an optional request_keys method for handlers which would let people generate their own unique key based on their analysis of the request. Doing this would mean you would need to generate filenames based on the unique keys (probably by hashing, as in Cache::FileCache) and do an internal redirect to that file if available when someone sends a request that matches. Another thing that might be nice would be to store the TTL with the file rather than making the handler give it to you again each time. This is done in mod_proxy by putting an Expires header in the file and reading it before sending the file, but you could also store them in a dbm or something. Support for sending Expires headers automatically would also be useful. When I first thought about this problem, I wanted to do it the way Vignette StoryServer does: by having people link to the cached files directly and making the content generating code be the 404 handler for those files. That gives the best possible performance for cached files, since no PerlFixupHandler needs to run. The downside is that then you need an external process to go through and clean up expired files. It's also hard to handle complex cache criteria like query args. StoryServer does it by having really crazy generated file names and processing all the links to files on the way out so that they use the cached file names. Pretty ugly. I know you guys are pushing to get the book done, so don't feel pressured to address this stuff now. I think the current module looks more than good enough for an initial CPAN release. - Perrin
Re: Creating an installable web site.
On Thu, 6 Dec 2001, Luciano Miguel Ferreira Rocha wrote: * have on cd apache with mod_perl and postgresl in installable form with your data. Or have them already installed on the cd. The problem here is that the source for your entire site will have to be distributed too and available for everybody's eyes to see. You'll also have to have different apaches and postgres for every architecture your clients use, and you should configure them to use different ports than the normal ones and above 1024, so that they don't conflict with already running web servers and rdbms. Also, they will have to be configured without absolute paths, and without any creation or writting to files (the cd medium is read-only, of course). As someone who currently helps maintain and develop similar installation software for the company I work for, this is not at all a trivial problem -- we have to install *everything*, Perl, Java, Apache, database software, as well as configure networking options, make sure they get properly reflected in the Apache configuration, turn on SSL if the client wants it. You can't make any assumptions about the system you are deploying on, other than the basics like having an installed OS, a shell, and a network card. Luckily we only deply on Solaris, which makes things a little easier. Having to support multiple platforms would be a PITA, especially since we have some custom-built C++ software (not to mention some C++ classes that get used with JNI). -- Brett http://www.chapelperilous.net/ Resisting temptation is easier when you think you'll probably get another chance later on.
Re: [RFC] Apache::CacheContent - Caching PerlFixupHandler
At 08:19 AM 12/06/01 -0800, Paul Lindner wrote: Ok, hit me over the head. Why wouldn't you want to use a caching proxy? BTW -- I think where the docs are cached should be configurable. I don't like the idea of the document root writable by the web process. Bill Moseley mailto:[EMAIL PROTECTED]
Re: CGI.pm 2.78 and mod_perl 1.26 troubles
On 6 Dec 2001, David Shrewsbury wrote: Solved it... apparently, if you upgrade CGI.pm while your web server is running, a restart is not good enough. You have to shutdown completely and then start it back up. yeah, especially if you're using mod_perl and have pre-loaded modules at server start up. -- Brett http://www.chapelperilous.net/ It is better to live rich than to die rich. -- Samuel Johnson
Re: [RFC] Apache::CacheContent - Caching PerlFixupHandler
On Thu, 06 Dec 2001 10:04:26 -0800 Bill Moseley [EMAIL PROTECTED] wrote: BTW -- I think where the docs are cached should be configurable. I don't like the idea of the document root writable by the web process. Maybe: Alias /cached /tmp/cache -- Tatsuhiko Miyagawa [EMAIL PROTECTED]
Re: [RFC] Apache::CacheContent - Caching PerlFixupHandler
On Thu, 6 Dec 2001 08:19:09 -0800
Paul Lindner [EMAIL PROTECTED] wrote:
I've attached a README below. To download it go to
http://www.modperlcookbook.org/code.html
Nice one. here's a patch to make the sample code work :)
--- CacheContent.pm~Thu Dec 6 22:11:35 2001
+++ CacheContent.pm Fri Dec 7 03:23:39 2001
@@ -6,6 +6,7 @@
@Apache::CacheContent::ISA = qw(Apache);
use Apache;
+use Apache::Log;
use Apache::Constants qw(OK SERVER_ERROR DECLINED);
use Apache::File ();
--- eg/CacheWeather.pm~ Thu Dec 6 08:10:09 2001
+++ eg/CacheWeather.pm Fri Dec 7 03:24:14 2001
@@ -8,7 +8,7 @@
use strict;
-@CacheWeather::ISA = qw(Cookbook::CacheContent);
+@CacheWeather::ISA = qw(Apache::CacheContent);
sub ttl {
my($self, $r) = @_;
--
Tatsuhiko Miyagawa [EMAIL PROTECTED]
Re: [RFC] Apache::CacheContent - Caching PerlFixupHandler
On Thu, 6 Dec 2001, Paul Lindner wrote:
On Thu, Dec 06, 2001 at 10:04:26AM -0800, Bill Moseley wrote:
At 08:19 AM 12/06/01 -0800, Paul Lindner wrote:
Ok, hit me over the head. Why wouldn't you want to use a caching proxy?
Apache::CacheContent gives you more control over the caching process
and keeps the expiration headers from leaking to the browser. Or
maybe you want to dynamically control the TTL?
sub ttl {
...
if ($load_avg 5) {
return 60 * 5;
} else {
return 60;
}
}
While a ttl might be useful to some projects, others I'm sure would prefer
a per-hit checking, so you can say Yes, this thing has changed now.
Just a thought.
--
Matt/
/||** Founder and CTO ** ** http://axkit.com/ **
//||** AxKit.com Ltd ** ** XML Application Serving **
// ||** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** mod_perl news and resources: http://take23.org **
\\//
//\\
// \\
Re: [RFC] Apache::CacheContent - Caching PerlFixupHandler
At 10:33 AM 12/06/01 -0800, Paul Lindner wrote: On Thu, Dec 06, 2001 at 10:04:26AM -0800, Bill Moseley wrote: At 08:19 AM 12/06/01 -0800, Paul Lindner wrote: Ok, hit me over the head. Why wouldn't you want to use a caching proxy? Apache::CacheContent gives you more control over the caching process and keeps the expiration headers from leaking to the browser. Ok, I see. Or maybe you want to dynamically control the TTL? Would you still use it with a front-end lightweight server? Even with caching, a mod_perl server is still used to send the cached file (possibly over 56K modem), right? Bill Moseley mailto:[EMAIL PROTECTED]
Re: [RFC] Apache::CacheContent - Caching PerlFixupHandler
On Thu, Dec 06, 2001 at 10:47:35AM -0800, Bill Moseley wrote: Ok, hit me over the head. Why wouldn't you want to use a caching proxy? Apache::CacheContent gives you more control over the caching process and keeps the expiration headers from leaking to the browser. Ok, I see. Or maybe you want to dynamically control the TTL? Would you still use it with a front-end lightweight server? Even with caching, a mod_perl server is still used to send the cached file (possibly over 56K modem), right? You definitely want a proxy-cache in front of your mod_perl server. One thing that I like about this module is that you can control the server-side caching of content separate from the client/browser cache. So, on to the RFC. Is the name acceptable for Apache::* I will endeavor to add any functionality that makes it worthy :) For example, I think adding a virtual method that generates the filename might be useful. -- Paul Lindner [EMAIL PROTECTED]| | | | | | | | | | mod_perl Developer's Cookbook http://www.modperlcookbook.org Human Rights Declaration http://www.unhchr.ch/udhr/index.htm
Tie Database Manipulation
Basel, Donnerstag, 6. Dezember 2001, 20:39:06 . Hello I'm just in some considerations for data handling using mysql. I can not decide if I should work directly with sql statements near the displaylogic (as I like sql, simple and quick) or if I should build some functions and pack them to the back. Regarding mod_perl with mason (to be in topic) what is slimmer? Probably the second is less resource using? Tieing sounds on top of it the best. Now if I would start here by zero I could not finish it before Christmas, and my first simple db manipulation on mod_perl/mason should be up and running next week ... ...does somebody have some suggestion to show me the WAY OF CODE to start on :-) Right now I would inspire myself on MySQLMan (my old stuff is really crap and each time different). Best Regards Christian - [EMAIL PROTECTED] - . == beginn original == Date: Donnerstag, 6. Dezember 2001, 05:30:49 Subject: ASP.NET Linux equivalent? You can also use the tie() feature of Perl to abstract read/write to database. In fact you can write a pretty flexible module to figure out many things, such as table name, col name, etc... Add Mason, EmbedPerl and you can compete with that company in Portland... what was their name? Micro...something... On Wed, 5 Dec 2001, Kee Hinckley wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At 6:55 PM -0500 12/3/01, Vsevolod Ilyushchenko wrote: Hi, Is anyone aware of a Linux product equivalent to ASP.NET from MS? Its most attractive feature is the GUI construction of Web forms and the automatic connection of their fields to a database. Since I am getting sick and tired of writing over and over the code to process user input and store it in the database, a similar product would be a huge help. (PHPLens does something The combo of Embperl and DBIx::Recordset will come pretty close to automating the fetch and store of database records into a form (perhaps four or five lines of embedded Perl for each). Designing the form is not there though. - -- Kee Hinckley - Somewhere.Com, LLC http://consulting.somewhere.com/ [EMAIL PROTECTED] (or ...!alice!nazgul for time travelers :-) I'm not sure which upsets me more: that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's. -BEGIN PGP SIGNATURE- Version: PGP Personal Security 7.0.3 iQA/AwUBPA48/CZsPfdw+r2CEQJbJQCg9Q++f5OUtiqBjdJMtBNuGu6HM8wAoKCz nXJM2ZccDeJH6y2Ael/+r1bh =SgDE -END PGP SIGNATURE- -- - Medi Montaseri [EMAIL PROTECTED] Unix Distributed Systems EngineerHTTP://www.CyberShell.com CyberShell Engineering - === end original
Re: [RFC] Apache::CacheContent - Caching PerlFixupHandler
On Thu, 6 Dec 2001, Paul Lindner wrote: On Thu, Dec 06, 2001 at 10:04:26AM -0800, Bill Moseley wrote: At 08:19 AM 12/06/01 -0800, Paul Lindner wrote: Ok, hit me over the head. Why wouldn't you want to use a caching proxy? Apache::CacheContent gives you more control over the caching process and keeps the expiration headers from leaking to the browser. Or maybe you want to dynamically control the TTL? You can use mod_accel to cache flexible backend: ftp://ftp.lexa.ru/pub/apache-rus/contrib/mod_accel-1.0.7.tar.gz mod_accel understands standard Expires and Cache-Control headers and special X-Accel-Expires header (it is not sent to client). Besides it allows to ignore Expires and Cache-Control headers from backend and set expiration by AccelDefaultExpire directive. Comparing to mod_proxy mod_accel reads backend response and closes connection to backend as soon as possible. There is no 2-second backend lingering close timeout with big answers and slow clients. Big answer means bigger then frontend kernel TCP-send buffer - 16K in FreeBSD and 64K in Linux by default. Besides mod_accel read whole POST body before connecting to backend. mod_accel can ignore client's Pragma: no-cache, Cache-Control: no-cache and even Authorization headers. mod_accel allow to not pass to backend some URLs. mod_accel allow to tune various buffer size and timeouts. mod_accel can cache responses with cookie-depended content. mod_accel can use busy locks and can limit number of connection to backend. mod_accel allows simple fault-tolerance with DNS-balanced backends. mod_accel logs various information about request processing. mod_accel can invalidate cache on per-URL basis. mod_accel has two drawbacks only - too much memory per connection (inherited Apache drawback) and Russian only documentation. Igor Sysoev
Re: [RFC] Apache::CacheContent - Caching PerlFixupHandler
Hello, PLThat's the price you pay for this functionality. Because we use PLApache's native file serving code we need a url-directory mapping PLsomewhere. PL PLOf course you don't need to make the entire docroot writable, just the PLdirectory corresponding to your script. Apologies if this is obvious--I haven't downloaded and tried this module yet. But would it not be possible to specify a separate directory altogether and make it serveable (Directory ... ... Allow from all ...)? If so perhaps it'd be easy to add this as a configurable parameter. In general it is a fine idea to not make the DocumentRoot writeable by the web user. In fact, I believe it is a good policy that the web user should be able to write only to a small subset of controlled locations. Humbly, Andrew -- Andrew Ho http://www.tellme.com/ [EMAIL PROTECTED] Engineer [EMAIL PROTECTED] Voice 650-930-9062 Tellme Networks, Inc. 1-800-555-TELLFax 650-930-9101 --
Re: [RFC] Apache::CacheContent - Caching PerlFixupHandler
On Thu, Dec 06, 2001 at 12:55:25PM -0800, Andrew Ho wrote: Hello, PLThat's the price you pay for this functionality. Because we use PLApache's native file serving code we need a url-directory mapping PLsomewhere. PL PLOf course you don't need to make the entire docroot writable, just the PLdirectory corresponding to your script. Apologies if this is obvious--I haven't downloaded and tried this module yet. But would it not be possible to specify a separate directory altogether and make it serveable (Directory ... ... Allow from all ...)? If so perhaps it'd be easy to add this as a configurable parameter. Yes, you can do this using the regular Apache directives: # mkdir /var/cache/www/mydir # chown apache /var/cache/www/mydir # vi /etc/httpd/conf/httpd.conf Directory /var/cache/www/mydir AllowOverride None Order allow,deny Allow from all /Directory Alias /mydir/ /var/cache/www/mydir/ In general it is a fine idea to not make the DocumentRoot writeable by the web user. In fact, I believe it is a good policy that the web user should be able to write only to a small subset of controlled locations. Yes, I agree totally! I'll add some warning to the docs to make sure that people do not inadvertently misconfigure their servers.. -- Paul Lindner [EMAIL PROTECTED]| | | | | | | | | | mod_perl Developer's Cookbook http://www.modperlcookbook.org Human Rights Declaration http://www.unhchr.ch/udhr/index.htm
PerlWarn and syslog
I am using apache+mod_perl and have: ErrorLog syslog PerlWarn On However the warning don't come out. If I change to ErrorLog /var/log/logfile or something similar then the warning start appearing. How do I get the warnings when syslog is used? Thanks, Lance
Re: PerlWarn and syslog
On Thu, Dec 06, 2001 at 02:11:28PM -0800, Lance Uyehara wrote: I am using apache+mod_perl and have: ErrorLog syslog PerlWarn On However the warning don't come out. If I change to ErrorLog /var/log/logfile or something similar then the warning start appearing. How do I get the warnings when syslog is used? I've seen various problems with Apache's built in syslog under mod_perl. The solution that I've been using lately is: ErrorLog | logger -p local3.debug If you just print to STDERR you might want to look at Apage::LogSTDERR on CPAN. -- Paul Lindner [EMAIL PROTECTED]| | | | | | | | | | mod_perl Developer's Cookbook http://www.modperlcookbook.org Human Rights Declaration http://www.unhchr.ch/udhr/index.htm
Re: PerlWarn and syslog
Hi there, On Thu, 6 Dec 2001, Lance Uyehara wrote: ErrorLog syslog Are you sure you want to do this? How do I get the warnings when syslog is used? There are some tips in Stas Bekman's new book, not yet published (you'll have to become a reviwer:) and you will find some help in the guide -- http://perl.apache.org/guide/porting.html#Apache_and_syslog 73, Ged.
Re: PerlWarn and syslog
Ged Haywood wrote:
Hi there,
On Thu, 6 Dec 2001, Lance Uyehara wrote:
ErrorLog syslog
Are you sure you want to do this?
How do I get the warnings when syslog is used?
There are some tips in Stas Bekman's new book, not yet published
(you'll have to become a reviwer:) and you will find some help in the
guide -- http://perl.apache.org/guide/porting.html#Apache_and_syslog
Too many people suggested that we plunge the syslog section because of
its slowness and unreliability. You should use log_spread instead if you
need to collect logs from many machines.
Since this section ss probably going away, here it is:
The syslog solution can be implemented using the following
configuration:
LogFormat %h %l %u %t \%r\ %s %b common
CustomLog | /usr/local/apache/bin/syslogger.pl hostnameX common
where a simple Isyslogger.pl can look like this:
syslogger.pl
#!/usr/bin/perl
use Sys::Syslog qw(:DEFAULT setlogsock);
my $hostname = shift || 'localhost';
my $priority = 'ndelay'; # open the connection immediately
my $facility = 'local0'; # one of local0..local7
my $priority = 'info'; # debug|info|notice|warning|err...
setlogsock 'unix';
openlog $hostname, $priority, $facility;
while () {
chomp;
syslog $priority, $_;
}
closelog;
The syslog utility needs to know the facility to work with and the
logging level. We will use Clocal0, one of the special logging
facilities reserved for local usage (eight local facilities are
available: local0 to local7). We will use the Cinfo priority level
(again one of eight possible levels: Idebug, Iinfo, Inotice,
Iwarning, Ierr, Icrit, Ialert, Iemerg).
Now make the syslog utility on the master machine (where all logs are
to be stored) log all messages coming from facility Clocal0 with
logging level Cinfo to a file of our choice. This is achieved by
editing the I/etc/syslog.conf file. For example:
local0.info /var/log/web/access_log
All other machines forward their logs from facility Clocal0 to the
central machine, therefore on all but the master machine we add the
forwarding directive to the I/etc/syslog.conf file (assuming that
the master machine's hostname is Cmasterhost):
local0.info @masterhost
We must restart the syslogd(8) daemon or send it the C-HUP kill
signal for the changes to take effect before the logger can be used.
_
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:[EMAIL PROTECTED] http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Problem with Apache::AuthCookie-3.00
Getting multiple HTTP replies returned to the client. They
get a form and followig it an 'access denied' message from
Apache.
The examples I've seen of login_form code use a simple print to
get things on the screen (e.g., Apache::AuthTicket).
I've tried this and various combinations of sending the headers
and form with no luck.
Ideally Apache::AuthCookie should only require the login_form,
authen_cred and authen_ses_key sub's to function with the
addition of login_screen to use a location rather rather than
#!-ed code for the login form.
Does anyone know of a simple, working example of deriving a
class from Apache::AuthTicket or some specific documentation
for a complete class? The code that comes with it is only
useful for testing; the other modules include quit a bit of
non-AuthCookie sub's that may have a bearing on how the
form is handled. The login_form is taken from Apache::AuthTicket
(basically just a header and static body).
My sub-class also overloads authentication to call login_form($r)
rather than without arguments.
sub authen_cred( $$\@ ) { foo }
sub authen_ses_key( $$$ ) { foo }
sub login_form
{
my( $class, $request ) = @_;
$request-no_cache( 1 );
$request-send_http_header( 'text/html' );
$request-print( $form );
OK
}
--
Steven Lembark 2930 W. Palmer
Workhorse Computing Chicago, IL 60647
+1 800 762 1582
cvs commit: modperl-site index.html
stas01/12/06 09:01:44 Modified:.index.html Log: - link to the mysql perl book (chapter 3 is modperl) Revision ChangesPath 1.95 +8 -0 modperl-site/index.html Index: index.html === RCS file: /home/cvs/modperl-site/index.html,v retrieving revision 1.94 retrieving revision 1.95 diff -u -r1.94 -r1.95 --- index.html2001/12/06 03:58:27 1.94 +++ index.html2001/12/06 17:01:44 1.95 @@ -324,6 +324,14 @@ /li li + Chapter 3 in the a + href=http://www.kitebird.com/mysql-perl/;MySQL and + Perl for the Web/a book, by Paul DuBois, is talking + about improving performance with mod_perl. + brbr + /li + + li Start learning mod_perl with a href=guide/the mod_perl Guide/a by Stas Bekman. brbr
cvs commit: modperl-2.0/t/response/TestModperl getc.pm
dougm 01/12/06 20:47:13
Modified:t/response/TestModperl getc.pm
Log:
always untie/tie STDIN
Revision ChangesPath
1.2 +2 -1 modperl-2.0/t/response/TestModperl/getc.pm
Index: getc.pm
===
RCS file: /home/cvs/modperl-2.0/t/response/TestModperl/getc.pm,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- getc.pm 2001/11/07 04:04:14 1.1
+++ getc.pm 2001/12/07 04:47:13 1.2
@@ -8,7 +8,8 @@
sub handler {
my $r = shift;
-tie *STDIN, $r unless tied *STDIN;
+untie *STDIN;
+tie *STDIN, $r;
while (my $c = getc) {
die got more than 1 char unless length($c) == 1;
