I have been trying to run a simple perl-cgi script on windows 7. This is a simple HTML form with an OK button where clicking on OK button displays some text. But clicking the OK button on the HTML page, instead of executing and displaying perl file's output, the browser starts downloading the script. I have added handler in httpd.conf
AddHandler cgi-script .pl
But this doesn't help. I added the ExecCGI option in the httpd.conf but that didn't help either.
<Directory "C:/Program Files/Apache Software Foundation/Apache2.2/cgi-bin">
AllowOverride None
Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>
Here is the perl script being used:
#!C:\Perl\bin\perl
use CGI;
print "Content-type: text/plain","\n\n";
print "<html>","\n";
print "<head>\n\t<title>Server Information Ready</title>\n</head>","\n";
print "<body>","\n";
print "<h1>Server Information</h1>","\n";
print "</body></html>","\n";
And here is the html file:
<html>
<head><title>Server Information</title></head>
<body bgcolor="#EEAA55">
<h3>Please click OK to get the server information</h3>
<hr><pre>
<form action="http://localhost/cgi-bin/ctest/pranav1a.pl" method="post">
<input type="submit" value="OK">
</form>
</hr></pre>
</body>
</html>
I have tried this on chrome, IE and Mozilla. Mozilla and chrome start the perl file download, but IE just displays some weird content on clicking the OK button. How can I make the browser display output of file execution rather than starting the script download ?
PS: I have tried to use shebang line as '#!c:/Perl/bin/perl' which doesn't seem to work either. I am able to see the perl script's output when executed from cmd prompt.
Found the solution: in my case I was using 'localhost' in form action instead of 'localhost:8080'.
<form action="http://localhost:8080/cgi-bin/pranav1a.pl" method="post">
How about the +ExecCGI option? Try the + in front of it.
In addition, these is usually a problem with understanding suexec2 (not sure whether suexec2 applies to a Windows platform):
Read the whole page over there. Such problems are not fixable when you do not understand the gross limitations enforced by suexec. Common errors are:
wrong permissions on suexec2 executable.
CGI script is located in wrong location.
Have you worked through apache.org/docs/2.2/howto/cgi.html#troubleshoot yet?
Thanks Scavokovich.
In my case the following line was commented out in the httpd.conf file.
#LoadModule cgi_module /opt/freeware/lib64/httpd/modules/mod_cgi.so
Uncommenting it, and restarting apache allowed the CGI script to run instead of open as a text file.
Related
On Ubuntu 16.04 when I try to open .php file on browser using http://localhost/vish+all it show blank page and a word 'yes' written on it . And due to this I am unable to acess php file on browser.
And I have php7.0 installed on it. What does word 'yes' means.
And how can I find solution for this?
You must need to verify if the php is a index.php and if is inside the command echo 'yes';
because echo <--- prints any character.
Example:
<?php
echo 'yes';
?>
also check your php.ini and check if your short_open_tag=On is ON because if is not your code will not work instead of
Also try to remove "+" from your directory or try to upload a new php called info.php and copy inside there the following code
<?php
phpinfo();
?>
Update: 07/12/13
The script works through command line.
"------extra line" is to show an extra return key stroke in editor.
XAMPP: 1.8.2
Server: Apache 2.4
Issue:
I keep receiving the error "End of script output before headers: hello.pl" for a simple hello world perl script. I'm trying to execute the script via a web server "xampp".
Curious Note:
I can use another Perl script which will initially work. However when I make a simple change such as a space, return or comment "#", the script will no longer function. However if I remove the change and save it the script will work again.
Check List
Confirm correct path to perl
Output header (see perl code below)
Extra line at end of script (I heard this could resolve issue)
Confirmed correct privileges in httpd.config
Transferred file via ftp in ASCII
Perl Script:
#!"C:\xampp\perl\bin\perl.exe"
print "Content-Type: text/html\n\n";
print "hello world";
------extra line
httpd.config
<Directory "C:/xampp/htdocs">;
Options Indexes FollowSymLinks Includes ExecCGI
AllowOverride All
Require all granted
</Directory>;
Maybe your editor changes the line ending characters to windows one.
CGI output needs to be started with HTTP.., two \n then header, then the body between the right HTML codes (Why doesn't my Perl CGI program work on Windows?)
Check the actual chars in a editor that shows you the line endings (like notepad++).
To my best knowledge, the shebang (#!) line is ignored in windows.
The probable cause:
http://perl.baczynski.com/wtf/solved-mystery-perl-on-xampp-wont-run-modified-scripts
tl;dr: turn off your COMODO antivirus, or it's sandbox feature.
Might be a known PHP bug (https://bugs.php.net/bug.php?id=66474). Try different versions of PHP?
Probably this is SELinux blocks.
try this
setsebool -P httpd_enable_cgi 1
chcon -R -t httpd_sys_script_exec_t cgi-bin/your_script.cgi
Disclaimer: I know this questions sounds lame. But I am no n00b and I have done whatever I know and I could find help about this. I have already searched the forum for this and tried all the fixes given but none of them helped me hence this question.
The threads I have visited
https://askubuntu.com/questions/147348/bugzilla-testserver-pl-failing
http://www.thesitewizard.com/archive/addcgitoapache.shtml
Bugzilla error after installation: "TEST-FAILED Web Server is not executing CGI files"
Now with that
My Exact problem
I have installed bugzilla on a bitnamil lampstack. The lampstack already has two other applications up and running successfully. After my bugzilla installation when I am trying to visit the page I can see my whole perl script on the borwser.
Running it's own server check reveals me the following
TEST-OK Webserver is running under group id in $webservergroup.
TEST-OK Got padlock picture.
TEST-FAILED Webserver is fetching rather than executing CGI files.
What I have done in my setup
The bugzilla.conf file (which gets pulled in httpd.conf) has the
following settings enabled
> AddHandler cgi-script .cgi .pl
>
> Options +MultiViews +ExecCGI
>
> DirectoryIndex index.cgi
>
> AllowOverride All
The "AddHandler cgi-script .cgi .pl" is already enabled in my httpd.conf file.
I have not enabled separately +ExecCGI for all directories in httpd.conf but even that does not solve the problem
What am I doing wrong here?
You should have a directory block in your bugzilla.conf that looks something like this:
<Directory "/usr/local/apache2/htdocs/bugzilla">
AddHandler cgi-script .cgi
Options +ExecCGI +FollowSymLinks
DirectoryIndex index.cgi index.html
AllowOverride Limit FileInfo Indexes Options
AddType application/vnd.mozilla.xul+xml .xul
AddType application/rdf+xml .rdf
</Directory>
I believe you don't want the .pl to be 'handled'. And having All for AllowOverride is a security issue. The FollowSymLinks one is because my bugzilla directory in htdocs is a symlink to somewhere else on the system.
Did you run the checksetup.pl? It should have adjusted all the permissions for you, but check to see that the group that your web server runs as has read and execute permissions.
I had a similar problem with another package downloading the CGI files instead of executing them on the server. The answer to my problem was that on Ubuntu server 14.04, the module CGI on apache was disabled.
To fix:
sudo a2enmod cgi
sudo service apache2 restart
To check if the module is loaded, on Ubuntu:
apache2ctl -M | grep cgi
cgi_module (shared)
yellavon's answer solved my problem:
cgi script is not executing
Here's a copy of his answer:
Make sure you are loading the CGI module in the httpd.conf file:
LoadModule cgi_module modules/mod_cgi.so or LoadModule cgi_module modules/mod_cgid.so depending on which version of Apache you are running.
You can also read about additional solutions for Dynamic Content with CGI.
While configuring with apache and perl cgi scripts, don't know why index.cgi/index.pl are displayed as plain text instead of executing them.
When I put http://localhost in browser it displays below code, instead of executing it.
List item
#!C:/Dwimperl/perl/bin/perl.exe -w
print "Content-type: text/html\n\n";
print <<HTML;
<html>
<head>
<title>A perl web page</title>
</head>
<body>
<h3>A hello world form perl</h3>
</body>
HTML
exit;
This are parts of httpd.conf file which I have edited most of the times (after reading various online reference, tutorials)
# This should be changed to whatever you set DocumentRoot to.
<Directory "D:\webserver">
Listen 80
ServerName localhost:80
LoadModule cgi_module modules/mod_cgi.so
# First, we configure the "default" to be a very restrictive set of
# features.
<Directory />
Options FollowSymLinks +ExecCGI
AllowOverride None
</Directory>
DirectoryIndex index.html index.html.var index.cgi index.pl
AccessFileName .htaccess
# To use CGI scripts outside of ScriptAliased directories:
# (You will also need to add "ExecCGI" to the "Options" directive.)
#
#AddHandler cgi-script .cgi .pl
ScriptAlias /cgi-bin/ "C:/Apache/Apache2/cgi-bin/"
When browser is printing code of script that means it's unable to find the application to run the script. Below two lines should be your first steps to solve this. AddHandler will make sure files ending with .cgi and .pl to be treated as cgi scripts. And +ExecCGI option will allow to execute the script. Also make sure your script is pointing to correct perl binary location.
AddHandler cgi-script .cgi .pl
Options FollowSymLinks +ExecCGI
Also There are some mistakes/misconfiguration points in your httpd.conf
Alias line should point to cgi-bin directory where your cgi scripts are present.
ScriptAlias /cgi-bin/ "D:\webserver\cgi-bin"
For same cgi-bin directory following configuration should be in httpd.conf. You should replace your <Directory "D:\webserver"> part with below.
<Directory "D:\webserver\cgi-bin" />
AddHandler cgi-script .cgi .pl
Options FollowSymLinks +ExecCGI
AllowOverride None
</Directory>
Try running your cgi script from command line like below. It should print or run from command line first.
perl test.cgi
Make sure you have read-write recursive permissions to cgi-bin directory and your cgi script. And also you can create directory or file with write permissions. If not create a cgi-bin directory at some other place where you can have write permissions and provide rather its path in alias and directory attributes in httpd.conf instead.
Check apache error log for exact error message every time you run into apache conf issues. It will give you good insight into the problem.
Also this link should help you.
(Extra comment, not by the original answerer: You may also need to enable the cgi module. For me, the final step to getting cgi to work on a fresh install of Apache 2 was sudo a2enmod cgi. Before I did that, the website simply showed me the contents of the script.)
sudo a2enmod cgi
The directory/location/file doesn't have the right handler associated with it, or doesn't have the ExecCGI option enabled. See Apache Tutorial: Dynamic Content with CGI.
change new version of apache :
Options +FollowSymLinks +ExecCGI
on mac os x 10.8
i had to do this
<Directory />
Options FollowSymLinks +ExecCGI
AllowOverride None
</Directory>
and
uncomment this
#AddHandler cgi-script .cgi .pl
# use types www.site.com/visible-in-url
# Apache serves /var/path/to/dir
ScriptAlias /visible-in-url/ /var/path/to/dir/
# Note the order of the aliases matters - first cgi than static content
# Note this dir is a symlink pointing to the desirable directory
<Directory "/var/path/to/dir">
AddHandler cgi-script .cgi .pl
AllowOverride Indexes
Options +ExecCGI +MultiViews +SymLinksIfOwnerMatch
Require all granted
</Directory>
<Files ~ "\.(pl|cgi)$">
SetHandler perl-script
PerlResponseHandler ModPerl::PerlRun
Options +ExecCGI +SymLinksIfOwnerMatch
PerlSendHeader On
</Files>
When browser is printing code of script that means it's unable to find
the application to run the script.
With Apache 2.4 (on OSX Yosemite, 10.10.5), if I use a shebang line with the wrong path, my browser displays:
Internal Server Error
But even with a valid shebang line, I could not get my cgi program to execute by following the advice in the accepted answer--Apache just served up the text of the program to my browser. After some experimenting, I found that the only change I needed to make to my /usr/local/apache2/conf/httpd.conf file was uncommenting the line:
LoadModule cgid_module modules/mod_cgid.so
My cgi programs have the extensions .pl, .py, and .rb depending on what language I'm programming in (and the apache cgi-bin directory contains a test cgi script with no extension), and they all execute without having to specify valid extensions anywhere in the httpd.conf file. My default httpd.conf file has only the following relevant lines:
<IfModule alias_module>
#Lots of comments here
ScriptAlias /cgi-bin/ "/usr/local/apache2/cgi-bin/"
</IfModule>
...
...
<Directory "/usr/local/apache2/cgi-bin">
AllowOverride None
Options None
Require all granted
</Directory>
The shebang line that I'm using is, depending on what language my cgi program is written in:
#!/usr/bin/env perl
or:
#!/usr/bin/env python
or:
#!/usr/bin/env ruby
A cgi program has to be an executable file as well, or else you will get an Internal Server error:
$ chmod a+x myprog.pl
a+x => all + executable. In other words, add the executable permission to each of owner, group, other.
And, at a minimum the cgi program has to generate a Content-Type header before outputting the body of the response:
print "Content-Type: text/html\n\n";
print "<h1>Hello, World.</h1>";
(By the way, that exact code will work in perl, python, or ruby.) Otherwise, once again you will get an Internal Server error.
The url to execute the cgi script:
http://localhost:8080/cgi-bin/myprog.pl
This is how I installed apache:
~/Downloads$ tar xvfz httpd-2.4.18.tar.bz2
...
...
~/Downloads$ cd httpd-2.4.18
...
...
~/Downloads/httpd-2.4.18$ ./configure --help
...
...
--enable-so DSO capability. This module will be automatically
enabled unless you build all modules statically.
...
...
I had no idea what the heck that meant, but the php docs say to install apache with that option, so I went ahead and did this:
~/Downloads/httpd-2.4.18$ ./configure --enable-so
...
...
~/Downloads/httpd-2.4.18$ make
...
...
~/Downloads/httpd-2.4.18$ sudo make install
Apache DSO docs here.
If nothing else has worked, be sure that you're displaying the HTML page that calls your executable script from the local server, e.g. http://192.168.0.15/yourPage.html. If you call it by opening the HTML page in your browser as a file, it will always display your executable script as a file.
How to disable mod_deflate for PHP using the.htaccess file
for files in a specific directory
for all files that have extension of, for example .php?
I have tried both:
# for URL paths that begin with "/foo/bar/"
SetEnvIf Request_URI ^/foo/bar/ no-gzip=1
# for files that end with ".php"
<FilesMatch \.php$>
SetEnv no-gzip 1
</FilesMatch>
They don't work, I can't figure out why. At this point I want to disable it completely for all files in the directory.
Check this out. and reply if it works for you:
SetEnvIfNoCase Request_URI ".php$" no-gzip dont-vary
Let's simplify the issue and slowly make it more complicated as you get each piece working.
First, you stated in a comment: "When I try to access a specific php file on the server FF tells me that that there is a compression problem"
First, see if the issue happens when you disable mod_deflate. Comment out the deflate lines from your apache configuration file(s).
If that indeed fixes it, re-enable mod_deflate, then add these to your virtualhost that is hosting your site (don't mess around with .htaccess yet, that just adds another level of complexity):
SetEnvIfNoCase Request_URI "\.(php)$" no-gzip dont-vary
Try PHP files and see if they are still compressed.
If this works, then add the other condition
SetEnvIfNoCase Request_URI "^/foo/bar/.*" !no-gzip !dont-vary
Finally - put this all in your .htaccess file and Ta-dah!