mod_perl2, CGI.pm and sending own headers

[Paul Raines <ra...@nmr.mgh.harvard.edu>]

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 have a mod_perl script area set tup with

     <Directory /home/httpd/facility>
         SetHandler perl-script
         PerlResponseHandler ModPerl::Registry
         PerlOptions -ParseHeaders
         Options +ExecCGI
         SSLRequireSSL
         AllowOverride FileInfo AuthConfig Limit
     </Directory>

I finally got most of the scripts working after going through
hours of the porting according to the migration documents which I found
very disorganized and incomplete.  I finally have all most all scripts
working except for one, which manages a repository of files of different
MIME types and serves them.  For this it needs control of the outgoing
HTTP headers to set content-type and content-length and such.  But
I cannot get it to work.  A short example that shows the problem is:

     #!/usr/bin/perl
     use CGI qw/:standard :netscape/;
     my $filepath "/tmp/foobar.pdf";
     my $mimetype = "application/pdf";
     my $size = ( -s $filepath );
     my $head = header(-type=>$mimetype,-nph=>1,
                  -Content_length=>$size,-expires=>'now');
     print $head;
     unless ($ENV{REQUEST_METHOD} eq 'HEAD') {
       open(FH,"<$filepath");
       my($br,$buf);
       while ($br=read(FH,$buf,1024)) { print $buf; }
       close(FH);
     }

With "PerlOptions -ParseHeaders" set above, this results in the header 
being printed at the top of the resulting web page with all the random PDF 
data junk after that.  Properties on the web page says the web page type is 
"text/plain".  So something is sending a header before giving me a chance 
to even though I have "PerlOptions -ParseHeaders" set.

If I try "PerlOptions +ParseHeaders" the only change is no header
is shown on the resulting web page, just the garbage of data.  Properties
still says the server gave a header of content type "text/plain".

How can I get the header I want to be the true HTTP header sent?

-- 
---------------------------------------------------------------
Paul Raines                email: raines at nmr.mgh.harvard.edu
MGH/MIT/HMS Athinoula A. Martinos Center for Biomedical Imaging
149 (2301) 13th Street     Charlestown, MA 02129	    USA

Re: mod_perl2, CGI.pm and sending own headers

[Paul Raines <ra...@nmr.mgh.harvard.edu>]

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.

Re: mod_perl2, CGI.pm and sending own headers

[Geoffrey Young <ge...@modperlcookbook.org>]

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.

> 
> 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

  use CGI qw/:standard :html3/;

  print header(-type           => 'application/pdf',
               -Content_length => 392,
               -expires        => 'now');

produces the following HTTP response

  HTTP/1.1 200 OK
  Date: Mon, 28 Aug 2006 16:49:18 GMT
  Server: Apache/2.2.2 (Unix) mod_perl/2.0.3-dev Perl/v5.8.8
  Expires: Mon, 28 Aug 2006 16:49:18 GMT
  Content-length: 392
  Connection: close
  Content-Type: application/pdf

followed by my data.  the config is simply

  <Location /registry>
    SetHandler perl-script
    Options +ExecCGI
    PerlResponseHandler ModPerl::Registry
    PerlOptions +ParseHeaders
  </Location>

which is the config from the ModPerl::Registry test suite.  in fact, I
just dunked a test script in the proper directory and fired up the test
suite and a telnet session to test it.

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.

HTH

--Geoff