smaller reset larger         

Main Menu

All times are in GMT -7 (DST) :: The time is now 5:50 am.

Sub Menu

Category Details
Category Name
CGIs and Scripts
Category Created
Wed, 23rd Mar 2011
Category Actions

   CGIs and Scripts

CGI doesn't work after upgrade from non-CGI-supporting account 

Add the cgi-bin alias and .cgi file extensions manually from the Web Options page.

View Full Article Add Comment

CGI scripts fail with a 404 not found 

First, make sure the account type you're using supports CGI scripts. As of this writing, the Atto account does not, while all others do. If your account does not support CGI scripts, you will need to upgrade.

If you have upgraded to an account that supports CGI, a manual step must still be done in order for CGI to work. See the related article for more information.

View Full Article Add Comment

Feedback Forms with Frontpage 

Feedback forms created in Microsoft Frontpage by default rely on what are known as the Frontpage Extensions. does not support the use of Frontpage Extensions, but you can still use feedback forms created with Frontpage by using the FormMail CGI script provides. Instructions for altering your Frontpage form can be found at

View Full Article Add Comment

formmail.cgi or PHP script that sends email no longer works 

The reason your email does not arrive is most likely a SPAM control issue.

When you send an email using a CGI or PHP script, Qmail (our sendmail stand-in) reads the enviroment to determine how to set the Return-Path variable. This is the email address that is reported to the recipient's email server as the sender and is not to be confused with the From: or Reply-To: headers in the actual email itself which exist for the benefit of the email client program.

The default Return-Path for CGIs is and for PHP is These addresses have stigmas (may be on some blacklists) attached to them due to previous abuses of CGI/PHP scripts on the servers and also because the users anonymous and root are suspect absent of the stigmas previously mentioned. Mail servers attempting to control SPAM may silently reject email with Return-Path headers containing those addresses or even as has been sufficiently abused as a sending host. While we try our best to prevent abuse of our system it has happend and these are the consequenses.

You can avoid this stigma by setting the Return-Path environment to something different. In a Perl based CGI, add somewhere near the top of you script:

$ENV{'MAILUSER'} = 'myusername';
$ENV{'MAILHOST'} = '';

In a PHP script calling the mail function, prior to the mail command, add:


This will set the Return-Path to '' and should allow your mail to pass through. If you are using the formmail.cgi AS SUPPLIED by the (H-Sphere) Control Panel, you can file a support ticket at and we will add the code free of charge.

It is our intention in the future to force these variables, but for now you will need to set them in your scripts.

View Full Article Add Comment

Internal Server Error 

The two most common causes of these errors are:

- A Perl script was not uploaded in ASCII mode. Because of differences in end-of-line conventions between different system these scripts must be uploaded in ASCII mode. Compiled programs, such as those written in C, must be uploaded in binary mode.

- The Perl path in the first line of the file is not correct. The correct path to use is listed in another document in this section.

View Full Article Add Comment

PHP scripts not interpreted 

Turn PHP off and back on from the Web Options page. Be sure to click the Apply changes link if it appears.

View Full Article Add Comment

Proper paths to use in CGI scripts 

The following paths should be used where required by your script:

Sendmail: /usr/sbin/sendmail

Perl: /usr/bin/perl

Home directory: /hsphere/local/home/username
(where "username" is your FTP username)

Web files directory: /hsphere/local/home/username/
(where "" is the domain in question)

View Full Article Add Comment

Proper permissions for CGI scripts 

Many CGI scripts will instruct you to modify the permissions on the script, its data files, and your directories. This is because, with many web hosts, you must severely relax access permissions on your files for CGI scripts to operate with them, due to the security scheme in place. (All user scripts run with the web server's "permissions" on the system.)
This is NOT necessary with QWK.Net servers. (Scripts run with your permissions, rather than the web server's.) In fact, changing some permissions on CGI scripts may cause the system to refuse to run them. Specifically, you must not change your CGI scripts to be writable by "group" or "other", or they will be rejected.

CGI scripts themselves must still be marked as executable to run, but you should not change any other permissions of the script, or your cgi-bin directory. If your software accepts a numeric permissions description, set your scripts to "755" permissions.

View Full Article Add Comment