Re: Converting section variables into plain text directives
On Fri, 24 Aug 2001, Eric Hammond wrote: > Is there any way to take the Apache::ReadConfig name space > (variables set in sections) and generate plain text > Apache directives? I don't know if there is a simple answer to this one, but the way I would handle it is to scrap the Perl sections, and generate the entire config file using a standalone perl script. Then just change your apache start script to first generate the config file, and then start Apache. This way you get the best of both worlds! Your config file is dynamically generated, and you can create a light apache without mod_perl. Since you already have a half perl, half text config file, It would probably be quite easy to use one of the many Template modules out there to simplify this process... I guess a module that does this automatically would be interesting, but it would really only be useful to recover from some bad planning :) (and I guess we've all been there at one point or another) Cees > For example, assuming some_function() returns "myhost", I would > like to convert the variables generated by: > > > $ServerName = some_function(); > $Port = 80; > > > into: > > ServerName myhost > Port 80 > > I have a hypothetical situation where a friend of a friend spent > a lot of time setting up a nice configuration for an > extended family of web servers with various requirements. He > then realized that one of the requirements was that some of the > web servers run without mod_perl (to serve static files and proxy > requests to separate mod_perl servers). > > My hypothetical friend of a friend is very embarrassed. > > After studying the instructions given in the Eagle book on how > to convert plain directives into variables, it seems that > it should be possible to traverse the name space in Apache::ReadConfig > and unwind the directives into something that standard mod_perl-less > Apache could process. > In fact, I have embarked on a project to build just such a tool. > > Before I go too far, though, I thought it would be helpful to seek > wisdom here. Perhaps somebody else has already done this? > Perhaps mod_perl already has the code embedded in it that could > be used? Perhaps some wish to tell me it is near impossible in > the general case and I should abandon my foolish quest? > > Of course, I realize that the output generated will not be able > to duplicate any side-effects or dynamic nature of code in the > sections. One of the requirements for using this utility will be > that you only need the end results stored in Apache::ReadConfig. > > I would be interested in suggestions for package naming if I do > succeed to an extent that others might be interested in using it. > Should I create a new method in the Apache::PerlSections name space > or would this be stepping on Doug's toes? > > Please do let me know if anybody else has a use for such a tool. > This will help me figure out how much time I should spend trying to > handle the general cases instead of just writing it to meet my... > er, my friend's... specific needs. > > Thanks > -- > Eric Hammond > [EMAIL PROTECTED] > -- Cees Hek SiteSuite Corporation [EMAIL PROTECTED]
Re: Connection Reset on Mandrake Linux 8.0 / Apache 1.3.20 / ModPerl 1.26
Tom Allen wrote: > ... > >AllowOverride None >Options ExecCGI Indexes >SetHandler perl-script >PerlHandler Apache::Registry >PerlSendHeader Off > > > It appears to work ( I get a webpage that says Hello!), in a Mozilla > browser, but httperf shows a connection reset instead of a success > message, the same goes for lynx (Alert!: Unexpected network read error; > connection aborted.). The ScriptAlias version works fine. The two > scripts can be seen online at > > Regular CGI version : http://www.nonserviam.net/perl/index.pl > ModPerl version: http://www.nonserviam.net/modperl/index.pl > When I test it, I get a 404 Not Found, which could explain it. But even when it is found, you might try setting PerlSendHeader On, as it may not send a header otherwise. Or you could try explicitly calling Apache->send_http_header in your mod_perl version. --Josh ]# lwp-request -eS http://www.nonserviam.net/modperl/index.pl GET http://www.nonserviam.net/modperl/index.pl --> 404 Not Found Connection: close Date: Sat, 25 Aug 2001 23:58:43 GMT Server: Apache/1.3.20 (Unix) mod_perl/1.26 PHP/4.0.6 Content-Type: text/html Client-Date: Sun, 26 Aug 2001 00:00:09 GMT Client-Peer: 65.34.152.103:80 Title: NonServiam! X-Powered-By: PHP/4.0.6 An Error Occurred An Error Occurred 404 Not Found
RE: URI munging and Referer headers
>I did some experimental work like this back when I first >implemented the cookiless session stuff for Apache::ASP, >and I found the same thing, that the meta refresh was really >the only way to go with redirecting offsite. This would >probably be the same for a javascript redirect too ( untested ). cool - thanks > >When it comes to session ids in URIs I also wonder about >cases like search engines indexing pages with them, and >then someone coming along later and using an old session id, >this really makes it important to garbage collect old >sessions so that this session id reuse doesn't hurt. Most >major search engines have a very large index refresh window >such that even old sessions that expire in a day should be >enough protection. I suppose that's true for unauthenticated state management, which I actually hadn't been thinking about - good point. --Geoff
Re: perlmagick and leaking memory
Jon Molin wrote: > > Hi list, > > I've done a scripts that builds an calender and colours the days with > different colours depending on the status of the day. I've got 6 colours > and one to just fill out so the month starts with the correct day, ie > i've got 6 * 31 + 1 = 187 images and each is about 70 bytes so a > calender is 6 times 7 of these little sqaures, about 3k. > > Now this little script handling this tiny amount of data runs amok and > grows and grows untill i restart apache brutaly, I guess I've done > something very wrong but I can't figure out what, nor can I find any > info about this. Here's what the program looks like: > Generally, I am not surprised when finding memory leaks in XYZ module. The code in the email looked fine, so I would suspect Image::Magick having the leak. To prove this better, you might take the code out of the mod_perl request, and run it through a test of 1000 iterations in a command line script, and report the problem to the author of Image::Magick. So, without waiting for a Image::Magick fix, you can make memory leaks less painful by setting MaxRequestPerChild lower, say to 100 or by using a solution like Apache::SizeLimit to kill a child process when it uses too much RAM ( unshared RAM on Linux too ) --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks Founder Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Re: URI munging and Referer headers
Geoffrey Young wrote: > > hi mungers... > > it there a more reliable way to not have your session id's show up in > Referer headers than using a refresh tag? I've played around with various > redirect methods, but both MSIE5 and Netscape4.7 hold on to the Referer from > the original page and ignore the 302 page. seems like meta refresh is the > only way to be sure. > > looking for expert opinions :) > I did some experimental work like this back when I first implemented the cookiless session stuff for Apache::ASP, and I found the same thing, that the meta refresh was really the only way to go with redirecting offsite. This would probably be the same for a javascript redirect too ( untested ). When it comes to session ids in URIs I also wonder about cases like search engines indexing pages with them, and then someone coming along later and using an old session id, this really makes it important to garbage collect old sessions so that this session id reuse doesn't hurt. Most major search engines have a very large index refresh window such that even old sessions that expire in a day should be enough protection. --Josh _ Joshua Chamas Chamas Enterprises Inc. NodeWorks Founder Huntington Beach, CA USA http://www.nodeworks.com1-714-625-4051
Converting section variables into plain text directives
Is there any way to take the Apache::ReadConfig name space (variables set in sections) and generate plain text Apache directives? For example, assuming some_function() returns "myhost", I would like to convert the variables generated by: $ServerName = some_function(); $Port = 80; into: ServerName myhost Port 80 I have a hypothetical situation where a friend of a friend spent a lot of time setting up a nice configuration for an extended family of web servers with various requirements. He then realized that one of the requirements was that some of the web servers run without mod_perl (to serve static files and proxy requests to separate mod_perl servers). My hypothetical friend of a friend is very embarrassed. After studying the instructions given in the Eagle book on how to convert plain directives into variables, it seems that it should be possible to traverse the name space in Apache::ReadConfig and unwind the directives into something that standard mod_perl-less Apache could process. In fact, I have embarked on a project to build just such a tool. Before I go too far, though, I thought it would be helpful to seek wisdom here. Perhaps somebody else has already done this? Perhaps mod_perl already has the code embedded in it that could be used? Perhaps some wish to tell me it is near impossible in the general case and I should abandon my foolish quest? Of course, I realize that the output generated will not be able to duplicate any side-effects or dynamic nature of code in the sections. One of the requirements for using this utility will be that you only need the end results stored in Apache::ReadConfig. I would be interested in suggestions for package naming if I do succeed to an extent that others might be interested in using it. Should I create a new method in the Apache::PerlSections name space or would this be stepping on Doug's toes? Please do let me know if anybody else has a use for such a tool. This will help me figure out how much time I should spend trying to handle the general cases instead of just writing it to meet my... er, my friend's... specific needs. Thanks -- Eric Hammond [EMAIL PROTECTED]
Re: Connection Reset on Mandrake Linux 8.0 / Apache 1.3.20 / ModPerl1.26
> I guess the only thing I don't understand is why > with PerlSendHeader Off, isnt the webserver supposed to send headers? > Does it not because it doesn't know what kind of content a .pl file is? > In that case, shouldn't it send DefaultType (text/plain) ? http://perl.apache.org/guide/config.html#_Location_Configuration (scroll down a bit) _ 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://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Connection Reset on Mandrake Linux 8.0 / Apache 1.3.20 / ModPerl1.26
On Sat, 25 Aug 2001, Philip Mak wrote: > I tried telneting to your web server to see what's going on. Look at this: > > $ telnet www.nonserviam.net 80 > Trying 65.34.152.103... > Connected to nonserviam.net. > Escape character is '^]'. > GET /modperl/index.pl HTTP/1.1 > Host: www.nonserviam.net > > Hello!Connection closed by foreign host. > > The HTTP server did not return a proper HTTP header, which is why lynx > doesn't like it. > > Looking at your mod_perl configuration... > > >PerlSendHeader Off > > Try doing it with PerlSendHeader On. You also might need to add this line > at the beginning of your script: > > print "Content-type: text/plain\n\n"; > > (or text/html) I just wanted to add that you always have to send 'Content-type' header. It's just that PerlSendHeader On reads your STDOUT, recognizes the header at a cost (see the guide) and then sends it along with other headers. With PerlSendHeader Off, you should use either CGI.pm or mod_perl native methods to set the headers. It's all in the guide :) _ 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://eXtropia.com/ http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
Re: Connection Reset on Mandrake Linux 8.0 / Apache 1.3.20 / ModPerl 1.26
Philip Mak wrote: > I tried telneting to your web server to see what's going on. Look at this: > > $ telnet www.nonserviam.net 80 > Trying 65.34.152.103... > Connected to nonserviam.net. > Escape character is '^]'. > GET /modperl/index.pl HTTP/1.1 > Host: www.nonserviam.net > > Hello!Connection closed by foreign host. > > The HTTP server did not return a proper HTTP header, which is why lynx > doesn't like it. > > Looking at your mod_perl configuration... > >>PerlSendHeader Off > > > Try doing it with PerlSendHeader On. You also might need to add this line > at the beginning of your script: > > print "Content-type: text/plain\n\n"; > > (or text/html) > > Thanks a million. I'm having one of those saturdays :-) It works like a champ, of course. I guess the only thing I don't understand is why with PerlSendHeader Off, isnt the webserver supposed to send headers? Does it not because it doesn't know what kind of content a .pl file is? In that case, shouldn't it send DefaultType (text/plain) ? Thanks again, I'm going to run autobench again and see if we get better results :)
Re: Connection Reset on Mandrake Linux 8.0 / Apache 1.3.20 / ModPerl1.26
I tried telneting to your web server to see what's going on. Look at this: $ telnet www.nonserviam.net 80 Trying 65.34.152.103... Connected to nonserviam.net. Escape character is '^]'. GET /modperl/index.pl HTTP/1.1 Host: www.nonserviam.net Hello!Connection closed by foreign host. The HTTP server did not return a proper HTTP header, which is why lynx doesn't like it. Looking at your mod_perl configuration... >PerlSendHeader Off Try doing it with PerlSendHeader On. You also might need to add this line at the beginning of your script: print "Content-type: text/plain\n\n"; (or text/html)
Connection Reset on Mandrake Linux 8.0 / Apache 1.3.20 / ModPerl 1.26
I installed ModPerl today, am excited, it seems to *mostly* work,
however, every request is ending in a connection reset error. This is
difficult to search for, since this is apparently a common problem in NT
under some situations. I am running :
Mandrake Linux 8.0 (kernel 2.4.3-20mdk)
Apache 1.3.20
ModPerl 1.26
This is the script I am running :
#!/usr/bin/perl -w
use strict;
if ($ENV{"MOD_PERL"}) {
print "Hello!";
} else {
print "I'm in slow motion :)";
}
I have two copies of the script, one running under ScriptAlias, the
other running Alias under mod_perl. Here is the location block for the
modperl version:
AllowOverride None
Options ExecCGI Indexes
SetHandler perl-script
PerlHandler Apache::Registry
PerlSendHeader Off
It appears to work ( I get a webpage that says Hello!), in a Mozilla
browser, but httperf shows a connection reset instead of a success
message, the same goes for lynx (Alert!: Unexpected network read error;
connection aborted.). The ScriptAlias version works fine. The two
scripts can be seen online at
Regular CGI version : http://www.nonserviam.net/perl/index.pl
ModPerl version: http://www.nonserviam.net/modperl/index.pl
Any thoughts / suggestions would be greatly appreciated.
Re: Modules `use`d by PerlModule vanishing after startup? (resend)
[EMAIL PROTECTED] (Stephen Clouse) wrote: >-BEGIN PGP SIGNED MESSAGE- >Hash: SHA1 > >On Fri, Aug 24, 2001 at 03:46:07PM -0700, ___cliff rayman___ wrote: >> 'PerlModule' in httpd.conf and 'use' in startup.pl perform the same >> purpose. if you are going to 'use' in startup.pl, comment out the >> PerlModule directive in httpd.conf. > >Except PerlModule is the only way to register Apache configuration >directives, which we define several, so we have to do it that way. But >the program doesn't work without the use in startup.pl, even though >PerlModule should load everything. Bizarre Hmm, as far as I know there are only 2 differences between 'PerlModule Foo' and 'use Foo;'. Config directive processing is one, and the other is that if the perl interpreter hasn't already started, PerlModule will delay loading the module until after it's started. So you might try putting an empty section in your httpd.conf prior to the PerlModule directive. ------ Ken Williams Last Bastion of Euclidity [EMAIL PROTECTED]The Math Forum
Re: [ADMIN] can we have a reply-to header?
On Wed, 15 Aug 2001, Thomas Eibner wrote: > Am I the only one that always have to go *doh* after I replied to a > message here? Well, the harm is much less than when you go *doh* after realizing that you sent something to thousands of people. In any case, the answer is "No." as long as I have access to the list configuration for the mod_perl lists[1]. :-) - ask [1] likewise for all the perl.org lists; munging the Reply-To header is just a bad idea and I wish it'd go away. -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than a billion impressions per week, http://valueclick.com
Re: Do virtual hosts need their own servers?
On Thu, 16 Aug 2001, Dave Baker wrote: [...] > p.s. The processes could also be large because of suboptimal > coding, Scalability problems are almost never due to bad code and almost always due to bad design. > or (if they grow over time) memory leaks ... with possibly that as the exception. :-) - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than a billion impressions per week, http://valueclick.com
Re: Do virtual hosts need their own servers?
On Thu, 16 Aug 2001, Jonathan Edwards wrote: > Related to this topic, I have a question about multiple > instances of Apache. We run two mod_perl enabled sites on two > separate IPs. These sites rely on mod_perl heavily. Each site > has a unique perl script that handles just about everything. > Currently, we only have one instance of Apache running, and I've > noticed that the httpd child processes are quite large (up to > 32megs!). We've upgraded the RAM on our server twice and now > we're at 512, but it seems to be using all of that without a > problem. Are these httpd processes so large because they include > copies of both perl scripts? Would it be more efficient to set > up two instances of Apache, one for each site/IP, and that way > each child httpd would only contain one of the two perl scripts? That might help some, but it all depends[tm]. What you really want is to setup a (reverse) proxy process in front of the mod_perl process. Try looking through my slides at http://develooper.com/modperl/ - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do(); more than a billion impressions per week, http://valueclick.com
