[prev in list] [next in list] [prev in thread] [next in thread] 

List:       apache-modperl
Subject:    Re: mod_perl2, CGI.pm and sending own headers
From:       Paul Raines <raines () nmr ! mgh ! harvard ! edu>
Date:       2006-08-28 17:29:52
Message-ID: Pine.LNX.4.62.0608281309590.27442 () gate ! nmr ! mgh ! harvard ! edu
[Download RAW message or body]

On Mon, 28 Aug 2006, Geoffrey Young wrote:

> Paul Raines wrote:
>>
>> I am having an extrememly frustrating experience getting my old
>> mod_perl1 scripts from a RedHat 7.3 server working on a new CentOS4 box
>> with Apache 2.0.52 server with mod_perl 2.0.1 with CGI.pm 3.11
>
> I'm sorry to hear that.  I would expect the migration of Registry
> scripts to be fairly painless, almost transparent.  handlers, sure, they
> would take some migration time.  but at any rate, I'm sorry you're
> frustrated.

With most of my scripts, code using pure CGI.pm things, except for this one 
thing the thread is about, nothing needed to change.  But CGI.pm still 
doesn't have access (as far as I could find) to lots of useful things and I 
used the mod_perl API directly.  Fore example, to log to the web server 
system error log I would do

$logger = Apache->request->log;
...
$logger->error("ERROR here");

and that completely changed with the mod_perl upgrade.

I also did have a handler I had to upgrade using perl Apache::AuthCookie 
and that was the most painful part. Actually, I had to deal with two 
mod_perl upgrades.  First, I upgraded from RH7.3 to CentOS4 (aka RHEL4) and 
the mod_perl 1.99 that comes with the later is some "partial" move from 
mod_perl 1 to 2.  I had to change several things in the handler to get it 
to work.  Then to install Request Tracker (RT) I had to upgrade to 
full mod_perl2 which broke everything again and I had to migrate again.

>
>>
>> I have a mod_perl script area set tup with
>>
>>     <Directory /home/httpd/facility>
>>         SetHandler perl-script
>>         PerlResponseHandler ModPerl::Registry
>>         PerlOptions -ParseHeaders
>
> I think if you take this out and also get rid of the -nph option here
>
>>     my $head = header(-type=>$mimetype,-nph=>1,
>                                         ^^^^^^^^^
>
> you'll be ok.  the script

Yes, removing the -nph seems to solve the issue.  But this confuses me as 
when I was original writing this under mod_perl 1.0 and CGI.pm 3.01 I found 
that I absolutely needed that -nph or I get the behavior where my header 
was ignored.  I am guessing doing "PerlOptions -ParseHeaders" is not 
exactly the same as the old "PerlSendHeader Off" as the later really put 
things in NPH mode and the new option does not.  THis should really be 
mentioned on the migration page.

Anyway, before you wrote your reply, I had found a solution by doing this:

     $r = Apache2::RequestUtil->request();
     $r->assbackwards(1);

I guess this really puts things in NPH mode (and maybe CGI.pm should
do this if -nph is passed to header()) but because of the name given
the function I am guessing the developers think it is the "wrong" thing
to do.

> I hope this resolves your problem.  in the future, please see
>
>  http://perl.apache.org/bugs/
>
> and follow the steps there so that you provide us the details about your
> installation, such as CGI.pm version, etc.

I would only think to use that for things I thought where definitely bugs 
and not to report things that might just be my misunderstanding or missing 
something in the migration issue.  I thought that was exactly the kind of 
thing this mailing list is for.  And I did report my installation and 
versions.
[prev in list] [next in list] [prev in thread] [next in thread]