Re: Poll - do you use Apache::Test custom configuration?
On Thursday, September 30, 2010 20:58:28 Fred Moyer wrote:
To simplify the Apache::Test codebase, the custom configuration
feature is being considered for removal. Is anyone here using that
feature? If you don't know what it is, you aren't using it.
For those of us who are a bit at a loss here, this is about data in
$ENV{HOME}/.apache-test and similar locations. The same information can be
passed via environment variables which is considered the better way.
Torsten Förtsch
--
Need professional modperl support? Hire me! (http://foertsch.name)
Like fantasy? http://kabatinte.net
Re: Poll - do you use Apache::Test custom configuration?
On 30 Sep 2010, at 19:58, Fred Moyer wrote: To simplify the Apache::Test codebase, the custom configuration feature is being considered for removal. Is anyone here using that feature? If you don't know what it is, you aren't using it. I don't believe we do, but could you give us a quick overview as to why and when we should consider it? Ta, smime.p7s Description: S/MIME cryptographic signature
Considering using Perl Sections
A while back I realized the futility of using a single httpd.conf after having many errors due to not repeating things correctly in SSL section and the long length of the file. I broke it up into a httpd.conf, mod_gzip.conf, a global SSL.conf and a conf file (and SSL version if needed) for each virtual host. Right now that is a total of 13 conf files. I like being able to diff the two versions for each virtual host to look for errors. Right now I am using Apache::AuthCookie to protect a variety of locations, but that is making things complicated again. At this point, should I break the AuthCookie sections out into confs for each virtual host using it, learn to use Perl Sections, or something different? Any suggestions are welcome. Thanks Chris Bennett
Re: Considering using Perl Sections
On 10/01/2010 04:47 PM, Chris Bennett wrote: At this point, should I break the AuthCookie sections out into confs for each virtual host using it, learn to use Perl Sections, or something different? Any suggestions are welcome. We actually like using templated httpd.conf files (we use HTML::Template, but you can easily use Template Toolkit, Text Template, etc). This lets us have really simple configs and then keep the stuff that's different for each client in a separate config file (or even the database) which is then pulled in and applied to the templated httpd.conf to generate the final conf. Works quite well for us. -- Michael Peters Plus Three, LP
RE: Considering using Perl Sections
We use a combination of Perl sections and Template Toolkit to generate our apache configs. The Perl sections are good for run-time setup for things like host names (i.e., to name logs per host in our cluster) and the templating is good for setting up things like multiple proxies that have just a few differences. In this case, I set up a data structure, and then iterate over it to generate the configs for the proxies. I also set up a utility script to deploy the whole shebang, since you can't use the templated configs as actual apche config files. Rendering these templates takes maybe 2 seconds, so I render my dev version against those that I've deployed to one of our DEV, STAGE, or PROD environments. Eric -Original Message- From: Chris Bennett [mailto:ch...@bennettconstruction.biz] Sent: Friday, October 01, 2010 4:47 PM To: modperl@perl.apache.org Subject: Considering using Perl Sections A while back I realized the futility of using a single httpd.conf after having many errors due to not repeating things correctly in SSL section and the long length of the file. I broke it up into a httpd.conf, mod_gzip.conf, a global SSL.conf and a conf file (and SSL version if needed) for each virtual host. Right now that is a total of 13 conf files. I like being able to diff the two versions for each virtual host to look for errors. Right now I am using Apache::AuthCookie to protect a variety of locations, but that is making things complicated again. At this point, should I break the AuthCookie sections out into confs for each virtual host using it, learn to use Perl Sections, or something different? Any suggestions are welcome. Thanks Chris Bennett ___ This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing. Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. ___
Re: Using a handler other than 'handler'
Cédric, Je schreef: Hello, I apologize for such a trivial question, but I'd like to use a function other than handler as a perl handler. According to the doc, it was possible in mod_perl 1, but I can't manage to get it to work under mod_perl 2. I am using Apache2::RequestRec which fine for me. I am using it as an AuthenHandler and as the starter for our restfull web application! Questions? Grtz, Michel
Re: All responses are 200 (server error)
On 9/27/2010 6:09 AM, Peter Janovsky wrote: Are you returning the value of 200 within a module you've written? I encountered a similar issue within a C module specific to valid requests. It was resolved by returning the internal constant OK. This is a generalized issue of serving ErrorDocuments; if they have a Status/ result code update (such as a backend proxy response or a cgi response), that will override the original error code. c.f. https://issues.apache.org/bugzilla/show_bug.cgi?id=49996 So it is not strictly a bug, but you certainly aren't the first to be frustrated by the behavior; look to the manner you handle ErrorDocuments with, first.
Considering using Perl Sections
A while back I realized the futility of using a single httpd.conf after having many errors due to not repeating things correctly in SSL section and the long length of the file. I broke it up into a httpd.conf, mod_gzip.conf, a global SSL.conf and a conf file (and SSL version if needed) for each virtual host. Right now that is a total of 13 conf files. I like being able to diff the two versions for each virtual host to look for errors. Right now I am using Apache::AuthCookie to protect a variety of locations, but that is making things complicated again. At this point, should I break the AuthCookie sections out into confs for each virtual host using it, learn to use Perl Sections, or something different? Any suggestions are welcome. Thanks Chris Bennett
