Re: CGI.pm and friends port to mp2
At least with some versions of perl, the require gets evaluated at compile
time and raises an exception even if it is enclosed by the eval {} braces.
The only way to get around this is to eval the string.
I'm not sure whether this is a current issue or was a problem with 5.00503,
but I've kept it in.
Lincoln
> - why eval string:
>
>eval "require mod_perl";
>
> shouldn't it be:
>
>eval { require mod_perl };
>
> ?
>
>
> __
> Stas BekmanJAm_pH --> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
--
Lincoln D. Stein Cold Spring Harbor Laboratory
[EMAIL PROTECTED] Cold Spring Harbor, NY
Re: the deprecation of Apache->request in mp2
I suppose there might be name clashes, but I'll look into doing that. Lincoln On Monday 24 March 2003 07:08 pm, Stas Bekman wrote: > Lincoln Stein wrote: > >>How about making CGI.pm a subclass of $r? (optionally of course, by > >>dynamically changing @ISA), so instead of returning $q it'll return $r, > >>after re-blessing it. > > > > Sounds interesting. What would be the advantage of that? > > The advantage is that > - you don't have to keep around two instances: $r and $q. > - assuming that CGI.pm-specific code is not used one can transparently > switch between Apache::Request and CGI.pm, by just changing: > > $r = Apache::Request->new($r); > $r = CGI->new($r); > > And of course Apache::Request is a subclass of Apache ($r) and it works > pretty well. > > In the future I can see someone extending Apache::Request to handle > CGI.pm's HTML generation in C, so the two could be replace each other. > > __ > Stas BekmanJAm_pH --> Just Another mod_perl Hacker > http://stason.org/ mod_perl Guide ---> http://perl.apache.org > mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com > http://modperlbook.org http://apache.org http://ticketmaster.com -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY
Re: speeding up CGI.pm
I like the idea of that, although the handsprings needed to do ordinary CGI, mp1 and mp2 might lead to a cloud of confusion. Best to keep them in separate modules and load them into CGI as needed. Is Apache::Request in mp2 ready for prime time? We haven't been able to get it running here (some sort of install problem, my people tell me). Lincoln On Tuesday 25 March 2003 03:25 am, Issac Goldstand wrote: > That would be really amazing if it could still be implemented in mp1, too, > as it would allow for interoperability between libapreq-based applications > (like Apache::UploadMeter) and response handlers like CGI scripts which use > CGI.pm I suppose that this isn't such a big problem in mp2 whose filters > will probably make using one API for request handling unnecessary... > > Issac > > - Original Message - > From: "Stas Bekman" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Tuesday, March 25, 2003 1:41 AM > Subject: speeding up CGI.pm > > > While we are at the CGI.pm issue, I was thinking that those who stick > > with CGI.pm because of its extended all-in-one functionality (request > > parsing/ > > HTML > > > generation), but unhappy about request parsing speed, could benefit by > > integrating Apache::Request in CGI.pm to do the request parsing. So if > > Apache::Request is available CGI.pm could re-alias its args(), params(), > > etc. > > > functions to call Apache::Request functions instead. What do you think? > > > > __ > > Stas BekmanJAm_pH --> Just Another mod_perl Hacker > > http://stason.org/ mod_perl Guide ---> http://perl.apache.org > > mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com > > http://modperlbook.org http://apache.org http://ticketmaster.com -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY
Re: the deprecation of Apache->request in mp2
> How about making CGI.pm a subclass of $r? (optionally of course, by > dynamically changing @ISA), so instead of returning $q it'll return $r, > after re-blessing it. Sounds interesting. What would be the advantage of that? Lincoln > > > The other issue is that it will only work with the OO form of CGI, which > > many people (including myself) don't use. > > You can still have an accessor function to set $r: > > use CGI; > CGI->r($r); > > > I would prefer a more transparent way to obtain the current request. Is > > there no low-overhead way of getting at this? > > Not, under threaded mpm. Since the code should work the same with threaded > and non-threaded mpm, it's a problem for any 2.0 code. The problem with > Apache->request is that it involves storing and retrieving data from the > TLS (thread local storage), which is slow. So while the functionality is > there, sites that are looking for high performance will want to pass $r, > rather than rely on Apache->request. > > Of course one can argue, that sites looking for high performance should use > Apache::Request (which is not quite there yet, for 2.0). So if this > argument is valid and you don't feel like changing the API, that's cool > too. May be in the future. > > __ > Stas BekmanJAm_pH --> Just Another mod_perl Hacker > http://stason.org/ mod_perl Guide ---> http://perl.apache.org > mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com > http://modperlbook.org http://apache.org http://ticketmaster.com -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY
Re: shim silence in Apache::MP3
Hi Sean, It sounds like a great idea, but it's not going to happen soon. My first priority is to get Apache::MP3 working with mod_perl 2.0 while maintaining compatibility with mod_perl 1.0.So much has changed between the two versions that I've basically given up on maintaining all my mod_perl scripts until I have a big chunk of free time (unlikely to happen soon, if ever). Lincoln On Monday 24 March 2003 08:05 am, Sean M. Burke wrote: > Me and Chris Nandor and Joe Johnston were just nattering on about frilly > little nicities would like (or have liked) in Apache::MP3. And I just > thought of one, hooboy! > > Namely: maybe an option for inserting 2s of silence between tracks, or > maybe just between tracks in different directories. What do you think? > Somewhere around here I have some mp3s and oggs of absolute silence, of > various runtimes, and even one with a runtime of 4 minutes 33 seconds, of > course. -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY
Re: CGI.pm and friends port to mp2
Did I send out something weird? My version looks like this:
# Turn on special checking for Doug MacEachern's modperl
if (exists $ENV{MOD_PERL}) {
eval "require mod_perl";
if (defined $mod_perl::VERSION) {
if ($mod_perl::VERSION >= 1.99) {
$MOD_PERL = 2;
require Apache::RequestRec;
require Apache::RequestUtil;
require APR::Pool;
} else {
$MOD_PERL = 1;
require Apache;
}
}
}
Lincoln
On Thursday 13 March 2003 06:21 pm, Stas Bekman wrote:
> Lincoln Stein wrote:
> > Please find enclosed a beta version of CGI.pm 2.92. I would appreciate
> > it if people could test it on both mod_perl 1 and mod_perl 2, as well as
> > under normal CGI scripts too ;-)
>
> Thanks Lincoln. 'make test' passes with mp1 and mp2, however the test
> suites aren't exhaustively cover CGI.pm's functionality. So we really need
> your help guys to give it a good test in the real apps.
>
> > In case anyone wonders why I fiddled with the check for the presence of
> > modperl, this is because some people write scripts that shell out to
> > command-line scripts that invoke CGI.pm in order to generate HTML (don't
> > ask me why). Without the additional checking, CGI.pm sees the MODPERL
> > environment variable, tries to load mod_perl outside the Apache
> > environment, and summarily crashes.
>
> Ahm, I'm not quite sure that this does what you say it should:
>
> if (exists $ENV{MOD_PERL}) {
>require mod_perl;
>if (defined $mod_perl::VERSION && ($mod_perl::VERSION >= 1.99)) {
> # mp2
>} else {
> # mp1
>}
> }
>
> because if it's not defined, it'll fall through to the else block, assuming
> that the external script is running under mp1. Shouldn't it be:
>
> if (exists $ENV{MOD_PERL}) {
>require mod_perl;
># mod_perl handlers may run system() on scripts using CGI.pm
># - make sure so we don't get fooled by inherited $ENV{MOD_PERL}
>if (defined $mod_perl::VERSION){ # for shell scripts
> if ($mod_perl::VERSION >= 1.99)) {
> # mp2
> } else {
> # mp1
> }
>}
> }
>
> also it's probably a good idea to add a note, why this check is done, so
> not to forget in the future and "optimize" it away ;)
>
> > I still haven't heard any response as to why I should move to MP2! I
> > wasn't just being cranky, I'm curious.
>
> You want to move to MP2, if one of the following reasons apply:
>
> - you are stuck with Apache2
> - you want to use i/o filters
> - you want to write your own protocol handlers
> - you want to use a threaded mod_perl
> - you are stuck with win32 (mp1 is unusable on win32, serialization)
>
> and there is a whole bunch of new functionality available, which will be
> too long to list here and partially described on the website.
>
> __
> Stas BekmanJAm_pH --> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
--
Lincoln D. Stein Cold Spring Harbor Laboratory
[EMAIL PROTECTED] Cold Spring Harbor, NY
Re: the deprecation of Apache->request in mp2
I can do this (changing the new() call to accept $r). My understanding is that client code will need to be changed to take advantage of this, right? The other issue is that it will only work with the OO form of CGI, which many people (including myself) don't use. I would prefer a more transparent way to obtain the current request. Is there no low-overhead way of getting at this? Lincoln On Thursday 13 March 2003 07:00 pm, Stas Bekman wrote: > One more issue with CGI.pm and mp2, and other modules as well. > > CGI.pm is using Apache->request. The setting/retrieval of the global > request record under threads is expensive, so the use of Apache->request is > deprecated in mp2. > > If CGI.pm can be changed to optionally accept $r (as an argument to new(), > plus a special accessor to set later) and use it instead, this will improve > the performance if Apache->request is not set. > > Notice that it's the enabling of 'PerlOptions +GlobalRequest' (it's on by > default with 'SetHandler perl-script') that is half of the performance hit > (store), and the actual use of Apache->request (get) is the second half. > > See: > http://perl.apache.org/docs/2.0/user/compat/compat.html#C_Apache_E_gt_reque >st_ http://perl.apache.org/docs/2.0/user/config/config.html#C_GlobalRequest_ > > __ > Stas BekmanJAm_pH --> Just Another mod_perl Hacker > http://stason.org/ mod_perl Guide ---> http://perl.apache.org > mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com > http://modperlbook.org http://apache.org http://ticketmaster.com -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY
Re: CGI.pm and friends port to mp2
Hi Stas, Thanks. I'll fold these changes and release on CPAN. I'll also remove the $|=1 setting, since that was globally needed for FastCGI compatibility, and I don't think that anyone uses it anymore. Lincoln On Monday 10 March 2003 08:43 pm, Stas Bekman wrote: > Hi Lincoln, > > > I'm not interested in modifying CGI.pm to use MP2 until I start using MP2 > > myself. This isn't likely in the near future, since I'm very happy > > indeed with MP1/Apache1. > > I've done the porting of CGI.pm, CGI::Carp and CGI::Pretty (no more > Apache/compat.pm). I did some basic testing, however it'd be nice if people > were to test this patch and confirm that I didn't break anything that did > work before. So that Lincoln doesn't have to figure out how to test it. > > I've attached the diff against 2.91 distro. > > One more thing, Lincoln, why CGI.pm does: > > $| = 1; > > without localizing the change, when running under mod_perl? This has a > potentially bad effect on the rest of the modules running under the same > server, since now every print() will flush the data. Can this setting be > localized (this will probably require to move the unbuffering where it's > relevant, rather than globally)? > > Thanks. > > __ > Stas BekmanJAm_pH --> Just Another mod_perl Hacker > http://stason.org/ mod_perl Guide ---> http://perl.apache.org > mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com > http://modperlbook.org http://apache.org http://ticketmaster.com -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY
Re: [mp2] automatic Apache::compat preloading in CPAN modules is a no-no
Hi Stas,
I'm not interested in modifying CGI.pm to use MP2 until I start using MP2
myself. This isn't likely in the near future, since I'm very happy indeed
with MP1/Apache1.
Lincoln
On Friday 07 March 2003 03:58 am, Stas Bekman wrote:
> Stas Bekman wrote:
> > Apache::compat is useful during the mp1 code porting. Though remember
> > that it's implemented in pure Perl. In certain cases it overrides mp2
> > methods, because their API is very different and doesn't map 1:1 to mp1.
> > So if anything, not under my control, loads Apache::compat my code is
> > forced to use the potentially slower method. Which is quite bad.
> >
> > Some users may choose to keep using Apache::compat in production and it
> > may perform just fine. Other users will choose not to use that module.
> > It should be users' choice.
> >
> > Therefore CPAN modules should *not* preload Apache::compat, but use the
> > mp2 API or copy the relevant parts from Apache::compat.
> >
> > Of course one can add an ugly workaround in startup.pl:
> >
> > $INC{'Apache/compat.pm'} = __FILE__;
> >
> > but I'd rather not have to remember doing that. I'll update the manpage
> > to have this warning.
> >
> > I haven't scanned the CPAN modules yet, but I've noticed that CGI.pm's
> > latest version does:
> >
> > require mod_perl;
> > if ($mod_perl::VERSION >= 1.99) {
> > eval "require Apache::compat";
> > } else {
> > eval "require Apache";
> > }
> >
> > Lincoln, any chance we can kill that preloading? If you need help with
> > porting the API please let us know.
>
> Here is a hopefully useful discussion and examples on how to get rid of
> Apache::compat:
> http://perl.apache.org/docs/2.0/devel/porting/porting.html#Handling_Missing
>_and_Modified_mod_perl_1_0_APIs
>
> __
> Stas BekmanJAm_pH --> Just Another mod_perl Hacker
> http://stason.org/ mod_perl Guide ---> http://perl.apache.org
> mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
> http://modperlbook.org http://apache.org http://ticketmaster.com
--
Lincoln D. Stein Cold Spring Harbor Laboratory
[EMAIL PROTECTED] Cold Spring Harbor, NY
Re: Does Apache::NavBar exist ?
That's right. CPAN is telling you to contact Doug and Me. Lincoln Does it exist ? > > > > Weird, it doesn't show up on search.cpan.org, but it seems to be on CPAN > > still: http://www.cpan.org/authors/id/B/BA/BARRACODE/ > > Otherwise you can find a copy here: > > http://modperl.com:9000/book/source/apachemod-code-1.02/lib/Apache/ > > Really strange. CPAN.pm finds it: > > cpan> m Apache::NavBar > Module id = Apache::NavBar > DESCRIPTION Navigation bar generator > CPAN_USERID MPB (mod_perl book (Doug and Lincoln) <[EMAIL PROTECTED]>) > CPAN_VERSION undef > CPAN_FILEContact Author mod_perl book (Doug and Lincoln) > <[EMAIL PROTECTED]> DSLI_STATUS bdpO (beta,developer,perl,object-oriented) > INST_FILE(not installed) > > But it doesn't know there is a copy on CPAN. I guess "BarracodE" > (Charles Day) is not registered as owner. > > I've Cc'ed the people involved. > > Lincoln, Doug, is this cleared with you? Andreas, if/when it is, can you > transfer the module? > > HTH, > Lupe Christoph
Re: possible buget in CGI.pm
I'm aware of the problem, but I haven't been able to track it down. Any help is welcome. Lincoln On Tuesday 23 July 2002 08:27 am, [EMAIL PROTECTED] wrote: > Hi All, > > We are implementing mod_perl here for internal intranet use. We have > discovered a possible buglet in CGI.pm. > > We do not want CGI.pm to return XHTML as it upsets Verity indexing (long > story). > > So in Apache::Registry executed scripts we use: > > use CGI qw( -no_xhtml ); > > But on the first invocation it returns normal HTML. On second invocation > it ignores this directive and returns XHTML. We started a dev server with > -X to confirm this. It would appear CGI resets its globals somewhere. > > Can someone confirm this? > > Also is this the right forum for this ? > > Which bit of the plot have I missed? > > Some versions: Apache 1.3.26, perl 5.6.1, mod_perl 1.27, CGI 2.81 > > Thanks, > > Greg Cope > > > > This message and any attachment has been virus checked by > Pfizer Corporate Information Technology, Sandwich. >
RE: inconsistency between CGI.pm and Apache::Request
No, it certainly isn't clean. Neither is Perl's API!
Lincoln
Matt Sergeant writes:
> > -Original Message-
> > From: Tatsuhiko Miyagawa [mailto:[EMAIL PROTECTED]]
> >
> > On Thu, 1 Nov 2001 09:58:39 -
> > Matt Sergeant <[EMAIL PROTECTED]> wrote:
> >
> > > I guess so. Your above is equivalent to:
> > >
> > > $r->param(foo => 'a', b => 'c');
> > >
> > > (foo => qw(a b c)) doesn't do what it looks like it does,
> > and that's a bad
> > > thing.
> >
> > I know! but CGI.pm does it, so what I want is interface
> > consistency. CGI.pm also has a named parameter style which
> > Apache::Request doesn't support, like
> >
> > $q->param(-name => 'foo', -value => [ qw(a b c) ]);
> > print join '/', $q->param('foo'); # a/b/c
>
> Well, as a libapreq developer, I'd say -1 to the above. I'm not that worried
> about consistency - it's not like they advertise as being the same (the
> wording in the README is "lighter and faster alternative"). For me the
> CGI.pm API isn't clean (sorry Lincoln :-)
>
> 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.
--
Lincoln D. Stein Cold Spring Harbor Laboratory
[EMAIL PROTECTED] Cold Spring Harbor, NY
NOW HIRING BIOINFORMATICS POSTDOCTORAL FELLOWS AND PROGRAMMERS.
PLEASE WRITE FOR DETAILS.
Re: inconsistency between CGI.pm and Apache::Request
I'm amazed that CGI.pm does this, but you're right. What's bad is
that this style doesn't work as expected:
p $r->param(foo=>[qw(a b c)])
Lincoln
Tatsuhiko Miyagawa writes:
> On Thu, 1 Nov 2001 09:58:39 -
> Matt Sergeant <[EMAIL PROTECTED]> wrote:
>
> > I guess so. Your above is equivalent to:
> >
> > $r->param(foo => 'a', b => 'c');
> >
> > (foo => qw(a b c)) doesn't do what it looks like it does, and that's a bad
> > thing.
>
> I know! but CGI.pm does it, so what I want is interface
> consistency. CGI.pm also has a named parameter style which
> Apache::Request doesn't support, like
>
> $q->param(-name => 'foo', -value => [ qw(a b c) ]);
> print join '/', $q->param('foo'); # a/b/c
>
>
>
> --
> Tatsuhiko Miyagawa <[EMAIL PROTECTED]>
--
Lincoln D. Stein Cold Spring Harbor Laboratory
[EMAIL PROTECTED] Cold Spring Harbor, NY
NOW HIRING BIOINFORMATICS POSTDOCTORAL FELLOWS AND PROGRAMMERS.
PLEASE WRITE FOR DETAILS.
Re: readdir()
Thanks everyone. I'll try backgrading to glibc 2.1. Does anyone know if the problem is still present in Perl 5.6.1? Lincoln Andrew Ho writes: > Hello, > > LS>Perl 5.6.0 breaks the readdir() function when running under mod_perl. > LS>This is with the most recent versions of Apache and mod_perl, as well > LS>as with older versions. I see the same problem reported in the > LS>mailing list going back to December 2000, but no hint of a > LS>resolution. Is there any fix? > > Are there references to the problem reports? readdir() works fine for me > with Apache 1.3.19, mod_perl 1.25, and Perl 5.6.0 on Solaris 2.7 (x86). > > 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 > -- -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY NOW HIRING BIOINFORMATICS POSTDOCTORAL FELLOWS AND PROGRAMMERS. PLEASE WRITE FOR DETAILS.
readdir()
Hi Doug, Perl 5.6.0 breaks the readdir() function when running under mod_perl. This is with the most recent versions of Apache and mod_perl, as well as with older versions. I see the same problem reported in the mailing list going back to December 2000, but no hint of a resolution. Is there any fix? Lincoln -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY NOW HIRING BIOINFORMATICS POSTDOCTORAL FELLOWS AND PROGRAMMERS. PLEASE WRITE FOR DETAILS.
Anticipated www.modperl.com outage
Just thought you folks might want to know that www.modperl.com will probably be unreachable for a day or two. NorthPoint communications has gone bankrupt, bringing my DSL connection down with it. I'm moving the server to another location for the interim, but it might take a day or two for the DNS changes to take effect. Lincoln -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY NOW HIRING BIOINFORMATICS POSTDOCTORAL FELLOWS AND PROGRAMMERS. PLEASE WRITE FOR DETAILS.
modperl back up
Hi All, As of last Friday, www.modperl.com is back up. The Apache::MP3 demo no longer works, unfortunately, because the thieves stole the hard disk that all the MP3s were on. I'm hoping to get it working again this week. Thank you for the several offers of help that I received. Lincoln -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY NOW HIRING BIOINFORMATICS POSTDOCTORAL FELLOWS AND PROGRAMMERS. PLEASE WRITE FOR DETAILS.
www.modperl.com
I regret to say that www.modperl.com is down again. This time it is because someone broke into my house and stole some computer equipment, including the DSL router. Fortunately the modperl web server itself was untouched because it was hidden in the eves. I will make an announcement when the system is back up. Lincoln -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY NOW HIRING BIOINFORMATICS POSTDOCTORAL FELLOWS AND PROGRAMMERS. PLEASE WRITE FOR DETAILS. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Updates to www.modperl.com site
Hi, I am very gradually making changes to the modperl book site. My plan over the next few weeks is to bring more of the examples online. Suggestions for priorities are very much appreciated. As of this morning, I have added an online demo of my Apache::MP3 module, which does nice directory listings of MP3 files and allows you to select and stream them. I also cleaned up the look of the page a bit, but it is still a bit primitive. Lincoln
www.modperl.com
The site should be up at its new location. Let me know if you see any problems with it. I haven't done much with it yet except for fixing a bug in one of the Hangman examples. It looked like a Y2K bug at first, because the cookie dates were set to 1969, but it was just an ordinary bug. Lincoln -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY
perlhandler -> CGI.pm -> no request object?
Would folks like to beta test CGI.pm version 2.57? "make test" will
fail with two html-related errors, but these are just related to
change in the HTML 4.0 DTD and nothing to worry about.
Lincoln
CGI.pm-2.57.tar.gz
Brian Reichert writes:
> Sorry about the confusing subject line.
>
> I'm witnessing a symptom:
>
> Using apache_1.3.9 and mod_perl-1.21 and CGI.pm-2.56 under 3.2-STABLE.
>
> I'm writing a cookie-based access handler. (Based very directly
> on the Apache::TicketMaster example in the Eagle book.)
>
> My perl handler uses:
>
> use CGI qw(:standard);
>
> then eventually calls
>
> header()
>
> Deep down, my error log says
>
> [Fri Jan 28 17:59:24 2000] [error] Can't call method "send_cgi_header" on
> an undefined value at (eval 11) line 50.
>
> Much digging shows that at around line 1278:
>
> my $header = join($CRLF,@header)."${CRLF}${CRLF}";
> if ($MOD_PERL and not $nph) {
> my $r = Apache->request;
> $r->send_cgi_header($header);
> return '';
> }
> return $header;
>
> the call to Apache->request returns an undef.
>
> The pod for Apache asserts:
>
>Apache->request([$r])
>
>The Apache->request method will return a reference to
>the request object.
>
> but fails to disclose under what cirumstances the call fails. I
> most certainly have an Apache request object at my disposal, my
> handler otherwise copes with it.
>
> Does anyone have any opinions or pointers?
>
> Thanks...
>
> --
> Brian 'you Bastard' Reichert [EMAIL PROTECTED]
> 37 Crystal Ave. #303 Daytime number: (781) 899-7484 x704
> Derry NH 03038-1713 USA Intel architecture: the left-hand path
--
Lincoln D. Stein Cold Spring Harbor Laboratory
[EMAIL PROTECTED] Cold Spring Harbor, NY
www.modperl.com
Hi, This site, which contains the examples for the "Programming Apache Modules in Perl and C" book, will be going down for a couple of days while I move it to a new ISP. When it comes back up I would like to add a few more online examples to the site and spruce it up a bit in general. Any votes on which examples you'd like to see put online? Lincoln -- Lincoln D. Stein Cold Spring Harbor Laboratory [EMAIL PROTECTED] Cold Spring Harbor, NY
