Re: mod_perl-1.2.6 for Cygwin 1.x (using apache_1.3.22, perl-5.6.1)
Stipe Tolj wrote: >>What is the problem with ld2? >> > > I'm using a patched version of ld which supports --auto-import. the official cygwin ld now supports --auto-import (and has since August 02.) --Chuck
@INC
How can I set this as my cgi's can't locate my libs? > Regards, > > Sean Plows
rookie question
Hello, I am completely new to the issue. My question is probably very straightforward but maybe you can help me out. I have made a monitor in perl which periodically overwrites static pages containing the output of various commands. The html pages are consisting of: multiple ascii text lines How can I easily make those pages dynamic ? (without the user doing a reload/refresh) Kind regards, Xavier Merlin
Re: [OT] Excellent article on Apache/mod_perl at eToys
> By the way, I noticed he documented still another gotcha due to a sneaky > closure. Does anyone know off-hand whether the Perl 6 folks plan to > change the closure syntax so they don't sneak into your code this way? > Closures, references, et al are being thoroughly revised, such that there will be far fewer gotchas. However, these kinds of memory leaks will be less of an issue anyway because Perl 6 will be garbage collected. Also, proper exception handling will be built into the language. PS: I haven't seen many of the regulars here on the Perl 6 lists. There's both language design and internals streams currently happening, so everyone's interests and skills should be catered for. Please have a look at http://dev.perl.org and consider getting involved. It's interesting work and there's a similarly positive and intellectual spirit on the P6 lists to what we experience here.
stacked handlers return vals
Hi, If I'm using stacked handlers, what should I return if I dont want the next handler in line to run because I've returned all required content to the client? (the eagle book says anything other than OK, DECLINED or DONE, but what's the appropriate return val that wont cause the client to think an error occured?) tnx!
Re: Problem using mod_perl-1.26 with perl 5.6.1 and XML::Parser
"Matthew H. Gerlach" wrote: > > Just to follow up. I took your advice on building building modperl. My actual > command was as follows: > > perl Makefile.PL \ > EVERYTHING=1 \ > USE_APACI=1 \ > APACHE_PREFIX=/lsurf/wohg \ > APACHE_SRC=../$APACHE/src \ > DO_HTTP=1 \ > APACI_ARGS="--enable-rule=expat --enable-module=so --enable-shared=info \ > --enable-shared=proxy --enable-shared=rewrite" > > I first tried this with perl 5.005_3 with no problems. I then upgraded to perl > 5.6.1, reinstalled the XML::Parser 2.30, and rebuild modperl/apache. The nasty > bug showed back up. At this point it still looks like I'm SOL using > XML::Parser with perl 5.6.1 under modper. > > I did download and install XML::LibXML and started playing with it. I'm > actually using XML::Parser via XML::Simple to put short XML "messages" into > handy 'data structures'. Maybe I should make an XML::LibXML::Simple :) > i would say that XML::LibXML is the most stable modules ive used everything else perl has failed for the X3D parsing tool i made: http://drfrog.fdns.net/perl/parsex3d.pl this will have a much nicer home at web3d.org at some point soon they found a bug in it on freebsd timezone related iirc
Re: Problem using mod_perl-1.26 with perl 5.6.1 and XML::Parser
Just to follow up. I took your advice on building building modperl. My actual command was as follows: perl Makefile.PL \ EVERYTHING=1 \ USE_APACI=1 \ APACHE_PREFIX=/lsurf/wohg \ APACHE_SRC=../$APACHE/src \ DO_HTTP=1 \ APACI_ARGS="--enable-rule=expat --enable-module=so --enable-shared=info \ --enable-shared=proxy --enable-shared=rewrite" I first tried this with perl 5.005_3 with no problems. I then upgraded to perl 5.6.1, reinstalled the XML::Parser 2.30, and rebuild modperl/apache. The nasty bug showed back up. At this point it still looks like I'm SOL using XML::Parser with perl 5.6.1 under modper. I did download and install XML::LibXML and started playing with it. I'm actually using XML::Parser via XML::Simple to put short XML "messages" into handy 'data structures'. Maybe I should make an XML::LibXML::Simple :) Thanks for the help, Matthew Matt Sergeant wrote: > > -Original Message- > > From: Matthew H. Gerlach [mailto:[EMAIL PROTECTED]] > > > > Now that I had something reproducible, I continued. I rebuilt using > > Apache 1.3.22 just like above, and everything continued to work. I > > upgraded to XML::Parser-2.30, and things continued to work. > > It was only > > when I went from perl 5.005_3 to 5.6.1 did my module break. As I said > > above I tried a statically linked apache. I also tried > > building Apache > > 1.3.22 as above with perl 5.6.1 and my code failed with both > > XML::Parser-2.29 and XML::Parser-2.30. Whatever way I tried > > using perl > > 5.6.1 I had my nasty problem. > > > > When configuring Apache 1.3.22 I noticed it said it was using the > > system's libexpat which was installed with RH. XML::Parser-2.29 uses > > its own copy of expat, but XML::Parser-2.30 uses the system libexpat. > > As I said with perl 5.005_3 I was able to use either version of > > XML::Parser. > > >From what I can tell from the Apache 1.3.22 build, here's how to get it > stable: > > 1. Install libexpat. > 2. Install perl > 3. Install XML::Parser 2.30 > 4. Install mod_perl and Apache, telling mod_perl to build Apache for you. > ** Do not use APXS to build mod_perl ** > > The recipe in the AxKit INSTALL file seems to work best for people doing XML > stuff inside mod_perl: > > $ perl Makefile.PL \ > > EVERYTHING=1 \ > > USE_APACI=1 \ > > DYNAMIC=1 \ > > APACHE_PREFIX=/opt/apache \ > > APACHE_SRC=../apache_1.3.22/src \ > > DO_HTTPD=1 \ > > APACI_ARGS="--enable-module=so --enable-shared=info > > --enable-shared=proxy --enable-shared=rewrite > > --enable-shared=log_agent" > $ make > $ su > $ make install > > However, that also builds Apache with --disable-rule=expat, so it might > kinda defeat your purpose :-) If you *really* need the expat in Apache, I > think you can add in there --enable-rule=expat, but I haven't tried it. > > If all that fails, switch to XML::LibXML or XML::SAX::PurePerl (actually, > think about doing that anyway :-) > > Matt. > > _ > This message has been checked for all known viruses by Star Internet > delivered through the MessageLabs Virus Scanning Service. For further > information visit http://www.star.net.uk/stats.asp or alternatively call > Star Internet for details on the Virus Scanning Service.
Re: Selectively writing to the access log
From: Mark Doyle <[EMAIL PROTECTED]>
> How about adding a custom header with the format you want
> and then logging that with a custom log format?
I think I've found an acceptable method. I've got a log handler like this:
my $req = $r->the_request;
if ($r->uri =~ /$something_interesting/) {
$req =~ s/$stuff/$other_stuff/;
}
$r->subprocess_env('THE_REQUEST', $req);
Then I'm using a custom log format like this:
LogFormat "%h %l %u %t \"%{THE_REQUEST}e\" %>s %b \"%{User-Agent}i\"" req_overload
---
Rodney Broom
Re: Selectively writing to the access log
How about adding a custom header with the format you want and then logging that with a custom log format? Cheers, Mark On Friday, October 19, 2001, at 04:09 PM, Rodney Broom wrote: > My ultimate goal is this: > I have a silly redirector script that acts as a logging hook for folks > clicking their way out of the site. The hit a link like > redir.cgi?dest=abc. My client has a web report that displays by > document, meaning that all of these redirects would show up in the > report lumped together as though they were equivilant. What I want is > to change the access_log entry for sake of that report, so I'd > essentially have mappings like: > > redir.cgi?dest=abc => redir_abc.html > redir.cgi?dest=jack => redir_jack.html > > This will break out the individual redirection requests in a way that > makes sence in a human-readable report. > > Make sence? > > > --- > Rodney Broom > > >
Re: Selectively writing to the access log
> Usage: Apache::the_request(r) This means the "sub" Apache::the_request takes a single parameter, i.e. you can't modify the_request. You can modify the method and uri. You can't modify the protocol (HTTP/1.0). If you change method or uri, it doesn't change "the_request". You can change your LogFormat to get these values--see http://httpd.apache.org/docs/mod/mod_log_config.html Rob
Re: Selectively writing to the access log
- Original Message - From: Mark Doyle <[EMAIL PROTECTED]> > I missed your original post, but maybe this will help. > > What about creating a new log using CustomLog and tying it to an > environment variable and only setting this in the requests you want > to log? I do this to log subscriber activity in a separate log > (still goes to the main access_log with all non-subscriber activity > as well, but it doesn't really matter as the separate log file is > much smaller and only has the events I need to process). My ultimate goal is this: I have a silly redirector script that acts as a logging hook for folks clicking their way out of the site. The hit a link like redir.cgi?dest=abc. My client has a web report that displays by document, meaning that all of these redirects would show up in the report lumped together as though they were equivilant. What I want is to change the access_log entry for sake of that report, so I'd essentially have mappings like: redir.cgi?dest=abc => redir_abc.html redir.cgi?dest=jack => redir_jack.html This will break out the individual redirection requests in a way that makes sence in a human-readable report. Make sence? --- Rodney Broom
Re: Selectively writing to the access log
From: Geoffrey Young <[EMAIL PROTECTED]> > are you on an old version of mod_perl? from Changes: > $r->the_request can now be modified Good catch, yes I was using 1.19. I've moved a machine with 1.26 and r->the_request($string) no longer fails. However, with 1.26 none of changes I'm making to the request object are showing up in the access log. I was able to overload certain fields with 1.19. --- Rodney Broom
RE: Selectively writing to the access log
> -Original Message- > From: Rodney Broom [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 19, 2001 3:14 PM > To: [EMAIL PROTECTED] > Subject: Re: Selectively writing to the access log > > > From: Rob Nagler <[EMAIL PROTECTED]> > > > I don't think you can change the access log format, but you can > > modify the values. For example, you can set $c->user and > $c->remote_ip. > > Thanks Rob, this is helpful and it works. The value I'm > wanting to change is in r->the_request, but passing a value > to that method yeilds a usage message: > > Usage: Apache::the_request(r) > > This routine returns a string, so I assumed it would take a > string. I've tried passing other things always getting the > same message. I've glanced at mod_log_conf.c, and some core > code, but I don't see what I need to pass. are you on an old version of mod_perl? from Changes: =item 1.23 - April 20, 2000 ... $r->the_request can now be modified HTH --Geoff
Re: Selectively writing to the access log
From: Rob Nagler <[EMAIL PROTECTED]> > I don't think you can change the access log format, but you can > modify the values. For example, you can set $c->user and $c->remote_ip. Thanks Rob, this is helpful and it works. The value I'm wanting to change is in r->the_request, but passing a value to that method yeilds a usage message: Usage: Apache::the_request(r) This routine returns a string, so I assumed it would take a string. I've tried passing other things always getting the same message. I've glanced at mod_log_conf.c, and some core code, but I don't see what I need to pass. --- Rodney Broom
Re: [OT] Re: Excellent article on Apache/mod_perl at eToys
> Wasn't this "seasonal rush" at least partly caused by the so-called toywar > (www.toywar.com) between eToys.com (the online retailer) and etoy.com > (the art group)? There were a lot of DoS attacks (and some even uglier, nastier ones) in 1999 as a result of that. Most of that was dealt with through standard access control stuff, plus the throttling code that was mentioned in the article. The 2000 rush, which we built this new system for, was real customer traffic, although there's always some joker with a bot trying to buy all the PlayStation 2 units. - Perrin
[OT] Re: Excellent article on Apache/mod_perl at eToys
Hi! On Fri, Oct 19, 2001 at 09:59:18AM -0400, Drew Taylor wrote: > What I found most interesting was the detail of the extensive caching which > was implemented to survive the seasonal rush. Wasn't this "seasonal rush" at least partly caused by the so-called toywar (www.toywar.com) between eToys.com (the online retailer) and etoy.com (the art group)? As far as I remember this incident, eToys.com sued etoy.com (who were holding this domain since 1994) because of trademark delusion etc., which caused one of the first distrubuted DOS attacks against etoys.com. see: http://rtmark.com/etoymain.html -- D_OMM O_xyderkes M_echanenhttp://domm.zsi.at M_asteuei
Re: Excellent article on Apache/mod_perl at eToys
Andrew Ho wrote: > > Hello, > > I checked the list archives and it didn't look like this had been posted yet. > For those of you who haven't seen it yet... a great read on perl.com about > the Apache/mod_perl setup at eToys, co-authored by our own mod_perl > regular contributer Perrin Harkins. > > http://www.perl.com/pub/a/2001/10/17/etoys.html > That's so awesome, the single best piece of technical writing on the web I can remember in a long time. Thanks for sharing. By the way, I noticed he documented still another gotcha due to a sneaky closure. Does anyone know off-hand whether the Perl 6 folks plan to change the closure syntax so they don't sneak into your code this way? I wonder how many mod_perl authors have never been burned by one?
Location, SetHandler and Aliases in httpd.conf
Hi, sorry if this is slightly OT but I need some help getting my apache config straightened out. I want to set up Apache so that requests to the document root are handled by mod_perl, but requests to a special images directory are not handled by mod_perl. Currently I have it set up like so: -- Alias /art /usr/local/apache/htdocs/art SetHandler perl-script PerlHandler MyModule -- Apparently Location takes precidence over Alias because it's ignoring my Alias and going to my perl handler. Does anyone know a way to make it do what I'm trying to do?
Re: Selectively writing to the access log
> I only see methods for writing to the error log. I don't think you can change the access log format, but you can modify the values. For example, you can set $c->user and $c->remote_ip. Rob
Re: Excellent article on Apache/mod_perl at eToys
If memory serves, I think we had something like 20-30 proxy servers and I think, at the end, we had w21 through w112 for app servers, so something like 92 app servers. I don't remember how many search boxes though. Thanks for the article Perrin, I didn't know half of what you, Ollie, Chris, Adam, Doug, and others had put together. And secondly, thanks for teaching me all the stuff you did, I feel pretty lucky to have worked with you there. Brian Nilsen [EMAIL PROTECTED] On Fri, 19 Oct 2001, Perrin Harkins wrote: > > What I'd love to see is the avg spec and numbers of machines in each > > section. So how many proxy, mod_perl and search servers were required to > > give the phenomenal performance you managed to achieve. > > Well, this was a long time ago (I wrote the article over a year ago), and I > don't remember exactly. The proxy machines were pretty basic, the search > servers were heavy on CPU power, and the mod_perl servers were heavy on RAM. > There were a lot of machines in the cluster, but I don't remember exactly > how many and it changed over time. There were dozens of mod_perl servers > when the cluster was at its biggest. Most of them were idle for the > majority of the time, but they were all needed for the occasional peak load. > > I remember at one point I was feeling embarrassed about the number of > machines and I told one of our sysadmins that it might have been a better > strategy to get a big Sun box or two instead. He replied that a Sun box > with equivalent power would have cost about 10 times as much as what we paid > for our rackmounted Intel machines. After that, I didn't worry about it too > much. > > - Perrin > >
Selectively writing to the access log
I'm wanting to look at the request and optionally change what gets written to the access log. However, I only see methods for writing to the error log. I think I need to do this inside the request because I'm piping things with TransferLog and don't want to interupt that. But I don't mind another aproach. --- Rodney Broom
Re: Excellent article on Apache/mod_perl at eToys
> What I'd love to see is the avg spec and numbers of machines in each > section. So how many proxy, mod_perl and search servers were required to > give the phenomenal performance you managed to achieve. Well, this was a long time ago (I wrote the article over a year ago), and I don't remember exactly. The proxy machines were pretty basic, the search servers were heavy on CPU power, and the mod_perl servers were heavy on RAM. There were a lot of machines in the cluster, but I don't remember exactly how many and it changed over time. There were dozens of mod_perl servers when the cluster was at its biggest. Most of them were idle for the majority of the time, but they were all needed for the occasional peak load. I remember at one point I was feeling embarrassed about the number of machines and I told one of our sysadmins that it might have been a better strategy to get a big Sun box or two instead. He replied that a Sun box with equivalent power would have cost about 10 times as much as what we paid for our rackmounted Intel machines. After that, I didn't worry about it too much. - Perrin
RE: [Templates] Re: Excellent article on Apache/mod_perl at eToys
I work in a predominately M$ shop. AS a matter of fact, I am one of only two Perl/mod_perl programmers in a development department with 25 other programmers. Sometimes it feels like we are working in a vacuum. This list and articles like the eToys article along with the overwhelmingly superior performance of mod_perl/Apache vs. either M$ IIS/ASP or M$ IIS/ColdFusion are what make, at least for me, doing what I do for a living where I do it possible. If it weren't for our success with mod_perl/Apache I really believe that this project would have been converted to ColdFusion a long time ago. Anecdotal evidence like the eToys article only add to the growing body of evidence that what we do with mod_perl is really the best of the available alternatives. Not only doe Perrin deserve a pat on the back for his article, but everyone who promotes the use of these technologies should feel good about what themselves. --Joe Breeden --- If it compiles - Ship It! > -Original Message- > From: Drew Taylor [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 19, 2001 8:59 AM > To: Perrin Harkins; mod_perl List > Cc: Template Toolkit List > Subject: Re: [Templates] Re: Excellent article on Apache/mod_perl at > eToys > > > What I found most interesting was the detail of the extensive > caching which > was implemented to survive the seasonal rush. I look forward > to working on > a project one day that is big enough to warrant such a > system. All in all, > a most excellent and informative read. > > Thanks again for everything you've personally done for the > community! I > look forward to seeing those graphics. :-) > > At 09:49 AM 10/19/01 -0400, Perrin Harkins wrote: > >Thanks to all for the kind words. This article actually > went up a little > >bit before it was supposed to, and there should be a > revision going up soon > >with some grammatical fixes and a set of graphics to > illustrate parts of it. > >I'll post a follow-up when that happens in case anyone wants > to go and look > >at the pretty pictures. > > > >While we're on the subject, thanks to everyone who > contributed to the many > >open source projects that we used. We couldn't have done it > without you. > > Drew Taylor JA[P|m_p|SQL]H > http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker > mailto:[EMAIL PROTECTED] *** God bless America! *** > ICQ: 135298242 > > > >
RE: Excellent article on Apache/mod_perl at eToys
> > Thanks to all for the kind words. This article actually went > up a little > bit before it was supposed to, and there should be a revision > going up soon > with some grammatical fixes and a set of graphics to > illustrate parts of it. > I'll post a follow-up when that happens in case anyone wants > to go and look > at the pretty pictures. Hi Perrin What I'd love to see is the avg spec and numbers of machines in each section. So how many proxy, mod_perl and search servers were required to give the phenomenal performance you managed to achieve. thanks Clinton Gormley
Re: [Templates] Re: Excellent article on Apache/mod_perl at eToys
What I found most interesting was the detail of the extensive caching which was implemented to survive the seasonal rush. I look forward to working on a project one day that is big enough to warrant such a system. All in all, a most excellent and informative read. Thanks again for everything you've personally done for the community! I look forward to seeing those graphics. :-) At 09:49 AM 10/19/01 -0400, Perrin Harkins wrote: >Thanks to all for the kind words. This article actually went up a little >bit before it was supposed to, and there should be a revision going up soon >with some grammatical fixes and a set of graphics to illustrate parts of it. >I'll post a follow-up when that happens in case anyone wants to go and look >at the pretty pictures. > >While we're on the subject, thanks to everyone who contributed to the many >open source projects that we used. We couldn't have done it without you. Drew Taylor JA[P|m_p|SQL]H http://www.drewtaylor.com/ Just Another Perl|mod_perl|SQL Hacker mailto:[EMAIL PROTECTED] *** God bless America! *** ICQ: 135298242
Re: Excellent article on Apache/mod_perl at eToys
Thanks to all for the kind words. This article actually went up a little bit before it was supposed to, and there should be a revision going up soon with some grammatical fixes and a set of graphics to illustrate parts of it. I'll post a follow-up when that happens in case anyone wants to go and look at the pretty pictures. While we're on the subject, thanks to everyone who contributed to the many open source projects that we used. We couldn't have done it without you. - Perrin
RE: Excellent article on Apache/mod_perl at eToys
> -Original Message- > From: Gunther Birznieks [mailto:[EMAIL PROTECTED]] > Sent: Friday, October 19, 2001 6:47 AM > To: mod_perl List > Cc: Template Toolkit List > Subject: Re: Excellent article on Apache/mod_perl at eToys > > > Yeah we really enjoyed it over here. I think it's really > excellent to get > great advocacy articles about Perl and surrounding products > (mod_perl, TT, > etc) powering real businesses with real high powered needs > out there like > this one. > > :) I particularly like the part about sending a router up in flames. That came across a little better at ApacheCon - maybe the article needs some flaming icon or something ;) nice work Perrin (as usual) --Geoff
Re: rookie's question regarding dynamic html pages
EaOn 19 Oct 2001, Xavier Merlin wrote: > I would like to make those pages dynamic > > Maybe modperl can help. What do I need ? The Eagle Book: "Writing Apache Modules with Perl and C", ISBN 1-56592-567-X, by Lincoln Stein and Doug MacEachern. It is available from O'Reilley (www.oreilly.com) and of course from Jubilee Office Supplies (www.jubileegroup.co.uk). Stas Bekman's mod_perl Guide: http://perl.apache.org/guide/ Have fun! 73, Ged.
Re: Excellent article on Apache/mod_perl at eToys
Yeah we really enjoyed it over here. I think it's really excellent to get great advocacy articles about Perl and surrounding products (mod_perl, TT, etc) powering real businesses with real high powered needs out there like this one. :) At 04:40 PM 10/19/2001, Greg Cope wrote: >Andrew Ho wrote: > > > > Hello, > > > > I checked the list archives and it didn't look like this had been > posted yet. > > For those of you who haven't seen it yet... a great read on perl.com about > > the Apache/mod_perl setup at eToys, co-authored by our own mod_perl > > regular contributer Perrin Harkins. > > > > http://www.perl.com/pub/a/2001/10/17/etoys.html > > > >Yup, this is an excellent read. Thanks Perrin. > >Greg __ Gunther Birznieks ([EMAIL PROTECTED]) eXtropia - The Open Web Technology Company http://www.eXtropia.com/
rookie's question regarding dynamic html pages
Hello, I am a rookie in this, so I am probably asking trivial things here. My current environment is: Windows NT 4.0 SP 5, Apache 1.3.9 Active state perl 522 I have written a perl monitor which writes simple static html pages having the format multiple ascii lines (output of the various monitors) I would like to make those pages dynamic Maybe modperl can help. What do I need ? Any experiences, example(s) ? Should I need the following described in http://theoryx5.uwinnipeg.ca/pub/other/perl-win32-bin-0.7.readme ? Your help is greatly appreciated Tnx Xavier
RE: Problem using mod_perl-1.26 with perl 5.6.1 and XML::Parser
> -Original Message- > From: Matthew H. Gerlach [mailto:[EMAIL PROTECTED]] > > Now that I had something reproducible, I continued. I rebuilt using > Apache 1.3.22 just like above, and everything continued to work. I > upgraded to XML::Parser-2.30, and things continued to work. > It was only > when I went from perl 5.005_3 to 5.6.1 did my module break. As I said > above I tried a statically linked apache. I also tried > building Apache > 1.3.22 as above with perl 5.6.1 and my code failed with both > XML::Parser-2.29 and XML::Parser-2.30. Whatever way I tried > using perl > 5.6.1 I had my nasty problem. > > When configuring Apache 1.3.22 I noticed it said it was using the > system's libexpat which was installed with RH. XML::Parser-2.29 uses > its own copy of expat, but XML::Parser-2.30 uses the system libexpat. > As I said with perl 5.005_3 I was able to use either version of > XML::Parser. >From what I can tell from the Apache 1.3.22 build, here's how to get it stable: 1. Install libexpat. 2. Install perl 3. Install XML::Parser 2.30 4. Install mod_perl and Apache, telling mod_perl to build Apache for you. ** Do not use APXS to build mod_perl ** The recipe in the AxKit INSTALL file seems to work best for people doing XML stuff inside mod_perl: $ perl Makefile.PL \ > EVERYTHING=1 \ > USE_APACI=1 \ > DYNAMIC=1 \ > APACHE_PREFIX=/opt/apache \ > APACHE_SRC=../apache_1.3.22/src \ > DO_HTTPD=1 \ > APACI_ARGS="--enable-module=so --enable-shared=info > --enable-shared=proxy --enable-shared=rewrite > --enable-shared=log_agent" $ make $ su $ make install However, that also builds Apache with --disable-rule=expat, so it might kinda defeat your purpose :-) If you *really* need the expat in Apache, I think you can add in there --enable-rule=expat, but I haven't tried it. If all that fails, switch to XML::LibXML or XML::SAX::PurePerl (actually, think about doing that anyway :-) Matt. _ This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Scanning Service. For further information visit http://www.star.net.uk/stats.asp or alternatively call Star Internet for details on the Virus Scanning Service.
Re: Excellent article on Apache/mod_perl at eToys
Andrew Ho wrote: > > Hello, > > I checked the list archives and it didn't look like this had been posted yet. > For those of you who haven't seen it yet... a great read on perl.com about > the Apache/mod_perl setup at eToys, co-authored by our own mod_perl > regular contributer Perrin Harkins. > > http://www.perl.com/pub/a/2001/10/17/etoys.html > Yup, this is an excellent read. Thanks Perrin. Greg
Re: Apache::RequestNotes and sharing information
>The PerlAccessHandler sets a session_based cookie, using TIEHASH
>$r->pnotes("COOKIES")->{'SESSION_ID'} = $session{_session_id};
Unless you have already stored a hash ref in pnotes with key COOKIES, you
must write:
$r->pnotes("COOKIES", {'SESSION_ID' => $session{_session_id}}) ;
this stores a new hash ref in the pnotes table. Then it should work
Gerald
-
Gerald Richterecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED] Voice:+49 6133 925131
WWW:http://www.ecos.de Fax: +49 6133 925152
-
