Apache::Sandwich, etc
Hi All, I am wondering if it is possible to add a footer to dynamic pages, server-wide, like the subject module does to static pages. One apparent way to me is to add another content handler, but I am not sure how that'll work. Any suggestion is appreciated. Jie
dont understand mem-mapping
I just cant get the following in my brain. I have a modules that is started with apache using the PerlModule-directive in httpd.conf. This module defines a global pointer on startup that should be the same in all sub-instances of httpd and really in the current apache-session all instances print out : $g_ptr : HASH(0x8458a30) This hashpointer is later filled with different values (dbhandles, filehandles ...) that should kept open over more calls. Now each session has the same pointer, but the content of the anonymous hash its pointing too is different in each instance !! thread 1: $g_ptr : HASH(0x8458a30) $g_ptr->{counter} : SCALAR(0x85aa62c) thread 2: $g_ptr : HASH(0x8458a30) $g_ptr->{counter} : SCALAR(0x85f5e2c) A even more strange example is an anonmous array that has the same adress, but different content too. The only explanation is that there is some mem-mapping for each httpd-instance, but I dont know much about this. My problem now is, that each httpd-instance opens a lot of db-handles and connections and I end up with system-errors 'to many files opened' or such things. Is there any way to share handles between all instances (I guess not, and I'm sure this mem-mapping has a deeper meaning too: if more than one instance access the same adress at the same time there would be lot of troubles and I'm even more sure that this has something to do with the copy-on-write feature of fork(), but I'm just not good in this things, so I'd like to have some comment to be sure that this is a principal problem and not a problem of my module) thnx, peter -- mag. peter pilsl phone: +43 676 3574035 fax : +43 676 3546512 email: [EMAIL PROTECTED] sms : [EMAIL PROTECTED] pgp-key available
[OT] Cookie woes
Hi everyone. This actually isn't mod_perl per se, but I'm hoping that other web developers might know something about this. I'm having cookie problems with, interestingly enough, both Netscape and MSIE. I'm setting a cookie in a page. Included in the page is an inline document (can be anything - CSS, pic, JS, DTD, XSLT - anything loaded inline). The browser requests to the inline pages do NOT include the cookie I've just set. Anyone know why this is, or even better: how to make these inline requests include the cookie? By the way, may as well mention what I'm seeing with both browsers. Netscape's simply not showing anything. MSIE actually does worse - if a cookie's just been expired, it'll send it (the old obsolete cookie) on the inline requests for some dumb reason, but won't send the new one until second time around... Any help would be... well... helpful :-) Issac Internet is a wonderful mechanism for making a fool ofyourself in front of a very large audience. --Anonymous Moving the mouse won't get you into trouble... Clicking it might. --Anonymous PGP Key 0xE0FA561B - Fingerprint:7E18 C018 D623 A57B 7F37 D902 8C84 7675 E0FA 561B
Re: RFC: Security/Performance Best Practices (long)
Philip Mak wrote: > Recently, I've been using Apache::ASP to program a new version of an > existing website that gets over 5 million page views per month. This > website will have to fit on a RaQ4i (450MHz) server, so I'm pretty > conscious about performance. Security is also important due to the > popularity of the site. > > I've read various documentation and combined them together into the > following strategy for security and performance on a mod_perl driven > website. I haven't seen these combined strategies formally written up > anywhere, so I thought I would try to do that and ask you guys for > suggestions. This is a bit unorganized right now, but all the general > concepts should be there. The goal is to produce a document that > explains all the principles, and shows all the configuration > directives required to accomplish this. I'm afraid there is no such a thing as a single detailed performance scenario fitting all users of mod_perl, I'd even say even a big chunk of users. Each user has a different hw, different requirements, different amount of $$, in-house knowledge and what not. So IMHO it'd be a mistake to even try to write an ultimate performance document. Hmm, may be such a thing could exist in winXX world, I don't know. You're heartly welcome to help to improve the existing documentation, which already sports I think about 200 printed pages of various scenarious, tips and tricks which comprise a "Lego"-like set for everybody to learn from and build their own bridge, their own monster and their own crane, using common components. Please don't create another documentation fork, unless you really have to, since it's so much easier for people to read all the docs from one place, rather than jumping between many scattered docs and of course avoid efforts duplication. Quite a few people have complained to me that while the mod_perl guide includes a lot of performance improvement techniques, it doesn't help newbies to make the right choice in first place. So they have to try a few of them first, before making the right choice. So if that's what you think is missing you are welcome to try to fill the gap, but personally I doubt it's possible for the reasons I've mentioned above and many other reasons. I just want to repeat that any attempt to improve the existing documentation and add new docs is very welcome and the 2.0 documentation project is going be the next cool thing if enough people will get involved and give help. You can check the modperl-docs cvs repository to see what's there so far. _ 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/
Re: RFC: Security/Performance Best Practices (long)
Philip Mak: > This website runs off a MySQL database. Although all the webpages > are generated dynamically, they don't change often (unless the > webmaster explicitly updates them). Do you generate reliable Last-Modified and Expires headers? This could help bandwidth usage for you and your users. -- Alessio F. Bragadini[EMAIL PROTECTED]
RFC: Security/Performance Best Practices (long)
Recently, I've been using Apache::ASP to program a new version of an existing website that gets over 5 million page views per month. This website will have to fit on a RaQ4i (450MHz) server, so I'm pretty conscious about performance. Security is also important due to the popularity of the site. I've read various documentation and combined them together into the following strategy for security and performance on a mod_perl driven website. I haven't seen these combined strategies formally written up anywhere, so I thought I would try to do that and ask you guys for suggestions. This is a bit unorganized right now, but all the general concepts should be there. The goal is to produce a document that explains all the principles, and shows all the configuration directives required to accomplish this. This website runs off a MySQL database. Although all the webpages are generated dynamically, they don't change often (unless the webmaster explicitly updates them). I setup a lightweight frontend httpd (port 80) that proxies to a heavyweight mod_perl backend httpd (port 8001). mod_gzip is installed on the frontend to deliver compressed HTML pages for faster download time. mod_proxy_add_forward is also installed so that the backend logs the true IP address of the request in its logs. In my account, I have these directories: httpd: apachectl, httpd.conf, logs for the mod_perl httpd perl: DocumentRoot for backend httpd web: DocumentRoot for frontend httpd global: contains *.pm, startup.pl, global.asa (for Apache::ASP) The proxying is configured in the frontend httpd.conf as follows: 1: RewriteEngine On 2: RewriteRule ^/(.+)\.asp$ http://127.0.0.1:8001/$1.asp [L,P] 3: RewriteRule ^/(.+)\.pl$ http://127.0.0.1:8001/$1.pl [L,P] 4: RewriteCond /home/aw/perl%{REQUEST_URI}index.asp -f 5: RewriteRule ^(.*)/$ http://127.0.0.1:8001$1/ [L,P] Line 2 passes any URL with a .asp extension to the backend. Line 3 passes any URL with a .pl extension to the backend. Line 4,5 passes any request for a directory to the backend, if there is an index.asp file in that directory. Notice that to the outside world, the hostname/port of the website is exactly the same whether it's being served by the frontend or backend. I prefer this approach since it lets my tags refer to images in the same directory, for example. It also doesn't require an extra DNS lookup on the client end (which it would if the mod_perl server and non-mod_perl server were on different hostnames). I don't have a ProxyPassReverse directive since I haven't thought about it; I wouldn't need it anyway since I don't do any redirecting (at least not right now), but I'll probably end up adding it just in case. The following users were created on the system: aw: I login as this user. Group = aw, httpd aw_guest: mod_perl httpd runs as this user. Group = aw httpd: lightweight httpd runs as this user. Group = httpd aw owns all of the files except httpd/logs. The "web" directory is world readable. It only contains images that everyone can get from the web server anyway. The "httpd" and "global" directories are group readable, so only aw and aw_guest can read it. "perl" is world readable, but the files inside are only group readable (this allows the httpd user to tell what files exist, but nothing more). This protects my source code (and the database passwords they contain!) from being browsed by others. So that I won't accidentally create world readable files, I have this line in ~/.profile for "aw": umask 027 This creates files as rw-r- by default. Files I upload by FTP still default to mode rw-r--r--, but I only upload image files that way (I use vi through ssh to edit the code) so that's perfect. There is a level of isolation here; in case I write an insecure script that gets hacked, the hacker will only gain access to the aw_guest account. The aw_guest account can read all my site's files, but it can't write to any of them. Also, the MySQL username/password used by the website has read-only access to the database. Apache::ASP is set so that every page has headers indicating that it can be cached for up to one hour: $Response->AddHeader('Last-Modified', time2str(time)); $Response->{CacheControl} = 'public'; $Response->{Expires} = 3600; I could have set the expiry time higher, but I decided to put it at 3600 so that in case I change content on the website and forget to manually clear the cache, it won't be out of date by more than 1 hour. In terms of performance issues, 1 hour should be long enough such that the backend httpd server doesn't have to do too much work. In my frontend httpd server, I have a basic cache configuration: ProxyRequests on CacheRoot /home/httpd/cache CacheSize 1 # cache size of 10 MB CacheGcInterval 1 # clean up the cache every hour CacheMaxExpire 24 # nothing lives in the cache for > 24 hours CacheDefaultExpire 1 # default expiry time is 1 hour I can force the frontend httpd server to reload a specific page from the backe
Re: OT: Internal server error on Refreshing mod_perl page ( Apache::ASP)
Hi again, On Sat, 10 Nov 2001 [EMAIL PROTECTED] wrote: > since my active server page knowledge is pretty much zero here is my > issue. Have several clients that use IIS w/lots of ASP[yuk] instead > of Apache && all things PERL. Richard and Josh have answered your other points, but I'd just like to take issue with this one, hoping that I won't offend. Comments like [yuk] will carry more weight if they are based on sound informed reasoning and not on prejudice. There is nothing wrong with being ignorant about a subject - as long as you are prepared to do something about it. But if you are not, you are in danger of becoming a religious zealot and we have ample evidence at the moment of where that leads us. Instead of disparaging the alternatives, learn about them. Know their strengths and their weaknesses. It seems to me that, so equipped, you might be in a position to give a more valuable service to your Clients. There is a lot to be said for Open Source, but even more to be said for an Open Mind. 73, Ged.