On 8/5/2014 5:35 PM, Nathan Andelin wrote:
I don't have experience with perl, but I came across one reference
which suggested to double check "file permissions" if you get "End of
script output before headers" errors.
Yeah, I went through that years ago when I first set it up on V5R4 (I'm
running a wiki on my i) [1]. The error message is apparently the Perl
CGI equivalent of MCH3601 'Something is broken enough that I can't tell
you much about it.'
What file permissions? I don't know. I would try runing chgaut with
subtree(*all) to grant authority to any directory-tree that contained
perl scripts. If that didn't fix the problem then grant authority to
any directory-tree containing perl object code.
None of the permissions changed.
None of the Perl files were replaced / touched by the upgrade from 7.1
to 7.2. It seems to me that the only material thing that changed is
Apache went from 2.2 to 2.4. I may put a call in to IBM but I suspect
they're going to tell me that I can't do what I'm doing.
--buck
[1] The way Perl is implemented is there's a Perl distribution that
comes with 5799-PTL
https://www-304.ibm.com/partnerworld/wps/servlet/ContentHandler/pw_com_porting_tools_index
This is an AIX version, so it runs under PASE.
PASE isn't like Windows in that there's no built-in recognition that a
file with a .pl extension should be invoked by Perl. To run a Perl
script under PASE, one invokes Perl, passing the script as a parameter:
perl env.pl
Apache has a similar issue. If my URL is something like
http://my.machine.name/env.pl, Apache needs to know how to pass that to
the Perl interpreter and then return the output to the browser. The way
it did that was through a wrapper written in Perl. In my posted
example, it is called apachedft:
#!/QOpenSys/perl/bin/perl
exec $ENV{PATH_TRANSLATED};
Apache knows how to execute this because of the following directives:
17 ScriptAlias /perl/ /QOpenSys/perl/webwrap/
18 AddType application/x-httpd-perl .pl
19 Action application/x-httpd-perl /perl/apachedft
20 Alias /perl-bin /www/apachedft/htdocs/perl-bin
21
22 <Directory /www/apachedft/htdocs>
23 Require all granted
24 </Directory>
25
26 <Directory /QOpenSys/perl/webwrap>
27 Options +ExecCGI
28 Require all granted
29 </Directory>
30
31 <Directory /www/apachedft/htdocs/perl-bin>
32 Require all granted
33 </Directory>
Line 17 maps the URI for line 19's use
Line 18 maps .pl to 'application/x-httpd-perl'
Line 19 maps 'application/x-httpd-perl' to the wrapper
22-24 allow the web page directory to serve web pages
26-29 allow access to the wrapper directory
31-33 allow access to the Perl script directory
I have a very simple Perl script called hello1.pl:
#!/QOpenSys/perl/bin/perl
print "Content-Type: text/html\n\n";
print "Hello, world!!!";
The line endings are all 0x0A, CCSID 819. This runs via QShell,
producing the expected output. I have a web page which has a link to
this script, URL '
http://my.machine.name/perl-bin/hello1.pl' Because it
ends with .pl, it ends up running the wrapper. The wrapper runs and
produces the following in the script error log:
===begin===
%% 500 /QOpenSys/perl/webwrap/apachedft
%request
Host: my.machine.name
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101
Firefox/31.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Cookie:
JSESSIONID=00007wzV5K334z4rJ_b0GwYOlav:6136c3e3-6cb8-4706-85ca-cff2ec3e57be
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
%response
Content-Type: text/html
Hello, world!!!
===end===
The error log shows:
[Wed Aug 06 10:08:03.530088 2014] [core:error] [pid 3228:tid 154]
[client 10.0.2.108:55809] ZSRV_MSG0947: End of script output before
headers: File name is apachedft
midrange.com
