SurfShopCart Documentation

Setting Up Shop Has Never Been Easier!

User Tools

Site Tools


troubleshooting_and_error_messages

Troubleshooting and Error Messages

Sometimes a little additional troubleshooting is necessary to get the program up and running. If you are not familiar with FTP, File permissions, CGI or Unix, read the section entitled Web Essentials elsewhere in this document.

500 Internal Server Error or "Premature end of script headers"

This is the most common problem that occurs with CGI scripts. It means the program crashed somewhere for some reason. 95% of our support questions are answered in the next several paragraphs. Start with (1.) and work your way down.

1. Incorrect "shebang" line

The first line of every Perl script (sometimes affectionately called the “shebang” line) must contain a pound sign (“#”), followed by an exclamation point (“!”), followed by the path to the Perl interpreter on the server. If there is ANYTHING before this line, or if the path is incorrect, the program will bomb. Your Web host can give you the correct path to Perl, however most systems will work with either of these two paths:

   #!/usr/local/bin/perl 
   #!/usr/bin/perl 

In some cases you must specify a particular version of perl in the shebang line.

   #!/usr/local/bin/perl5.004

This is unusual, but has been necessary for some installations.

2. Incorrect File Permissions

All of the perl scripts must be executable by the webserver. This might be 755 or 711, depending on your server configuration.

The data directory (and all other web directories) should be searchable and writable by the webserver. This might be 777 or 755, depending on the server configuration.

The data files should be writable by the webserver. This could be 666, 644 or 600, depeding on the server configuration.

The output files should be writable by the webserver. This could be 666, 644 or 600, depeding on the server configuration.

All of the other files should be read-only. This could be 644 or 600, depending on the server configuration.

Finally, some servers WILL NOT EXECUTE scripts if the directory permission is higher than 755. Make sure the surfshop directory is set to 755 and try again.

3. Inconsistent line endings (carriage returns) in the script file

Moving files across platforms will sometimes result in newlines being converted into newline-carriage return. Often this confuses the FTP program into thinking the file is a “binary” file, and the incorrect line endings get transferred to the web server. This will almost always cause the script to fail.

Try opening the script in a different text editor and re-saving it to your hard drive before FTPing it using the ASCII method.

Some editors add extraneous characters that will cause the script to crash. Whatever you do, DON'T use Word, WordPerfect, or any other 'word processing' program. You should only use a basic text editor like WordPad, Pico, SimpleText, or the like to work with any kind of program script. We suggest using a Developers Editor like BBEdit or CodeWarrior, both of whom have powerful search and replace features.

4. Incorrect data format (binary instead of ASCII text)

Try uploading the files to your server again, this time making sure you use the ASCII Text method for all scripts and HTML files. Most FTP programs will automatically convert the line endings to UNIX format.

5. Incorrect path configurations

Autoconfig.cgi attempts to detect the system variables, but you may need to modify them. Your Web host should be able to provide you with the correct file paths. Make sure that you have included or omitted slashes where required. Refer to the “Installation” section for specific details.

If you are using a secure server, make sure that the “Secure URL” setting does not contain the http:/ prefix or any trailing slashes. The “Path to Document Root” path is sometimes the culprit. Do not assume that the default path that SurfShop generates is correct! Try entering a single forward slash (“/”) for this setting.

Cannot Verify Referring URL Error at Checkout

SurfShop automatically checks the origin of any request to complete an order against the list of “valid” cardservice (Payment processing) providers. There are two possible causes of this error:

  • The request came in from a web address not listed in the “Cardservice Domains” Global setting;
  • The request came from a secure site, and your store is not SSL-enabled.

Solutions:-

  1. If you are using the “Allow payment by mail” option as well as a payment processor, you should add your domain to the list of valid cardservice domains.
  2. If you are not hosting your store on an SSL-enabled website, you should leave the “Cardservice Domains” field blank. This will bypass the “referring domain” check.

We strongly recommend using SSL with Surf Shop. Not doing so is a potential security risk and liability for your business. See Security.

One or more of the URL settings is incorrect. Run autoconfig.cgi and make sure you have entered all of the URL fields correctly. If you have set a password, delete the “.p” and “.l” files that were installed by autoconfig.cgi and start over.

    ssdata/1/data/.private/.p
    ssdata/1/data/.private/.l
    ssdata/1/data/.private/.auth
    ssdata/1/data/.private/.htpasswd
    ssdata/1/data/.private/.htaccess

Because of the countless variations of server configurations out there, it is necessary to specify all four of the following: Non-secure path to SurfShop™, Secure Path to SurfShop™, Non-secure path to the Document Root, and the Secure path to the Document Root. If you are installing SurfShop™ on a secure server ONLY, leave the “Non-secure” settings BLANK.

autoconfig.cgi keeps saying my data directory has not been installed correctly, but I know that it has

In order for SurfShop™ to function, autoconfig.cgi must write a file called “.datadir.dat” in the surfshop directory. A few servers do not allow cgi scripts to create files in the cgi-directory. If yours doesn't, try uploading a blank text file named “.datadir.dat” to the surfshop directory, setting its permission to read/write (666), and running autoconfig.cgi again.

"Document Contained No Data" pop up window in browser

This occurs when the browser receives a valid header, but does not receive any other information from the server.

Open ssdata/1/data/config.dat

Make sure that the following lines contain values:

   DefaultTemplate=main.htm
   OnErrorFile=stderr.htm

Often is caused when SurfShop tries to create a page from a template or file that is empty or does not exist, or is not where SurfShop thinks it is. Check that all the files are installed correctly.

Sometimes this is caused when a server is maxed out on memory or requests.

SurfShop™ is not sending email notifications

This is either because the “mail program” setting is incorrect in autoconfig.cgi, or the mail template used to generate the mail message is incorrect.

1. Double check the path to your server's mail program. The most common paths are:

   /usr/lib/sendmail
    - or - 
   /usr/sbin/sendmail 

Some servers are run qmail instead of sendmail, which will have the following path:

   /var/qmail/bin/qmail-inject 

2. The default mail templates may have inconsistent line endings causing the mail to be formatted incorrectly. Using the “Edit Email Messages” admin, make sure all the fields have values and submit the form to rewrite them.

   To: <! Ecom_BillTo_Online_Email> This is the recipient of the message 
   From: <! YourMail> This is the "reply-to" address 
   Subject: Your Order This is the subject line.
   Body: Thank you .... [etc.] This is the body of the message.

"We're Sorry Message" keeps appearing

This is SurfShop™'s standard error message. If you see this message, then you know the program is working, however one or more of the configuration settings is incorrect. Review the instructions for correct installation of SurfShop™ .

"Permission denied" or "Can't open..."

Either your permission settings are incorrect or the data directory has not been installed correctly. Review the instructions for correct installation of SurfShop™ .

"File not found"

This means either the files are not where they are supposed to be, the file paths are incorrect, or the permissions are incorrect. If your server configuration is different than the SurfShop™ defaults, you may need to manually set the <form> tags in the sample.html page and/or your catalog pages to make the program work.

"Invalid referrer" or "Could not verify the referring page"

SurfShop™ is set up to detect if anyone is trying to send it data from somewhere other than your host computer. If you are getting this error with legitimate CGI calls, then check the “domain,” “card service URL,” and “secure URL” settings in autoconfig.cgi for accuracy.

Microsoft Internet Explorer will not pass the referring URL from a SSL-enabled site to a non-secure site. This will cause the script to generate this error when returning from a payment processor. The work around is to remove the referring url from the “Cardservice Domain” global setting field. The referrer check is bypassed when this field is empty.

First, make sure the image in question is where you think it is. Most of the time the URL in the web page is incorrect. If you know it is correct, try making your URL's relative to the “root” rather than the “document,” that is, place a forward slash before the path to the image:

  /images/picture.gif

instead of:

   images/picture.gif 

SurfShop™ uses a special place holder, <! imageurl>, to generate a URL which will change for secure and non secure protocol. Try using this instead of a hard wired address in your HTML code:

   <img src="<! imageurl>/images/thispicture.gif">

My secure server cannot be accessed from my web server. How do I install SurfShop™?

SurfShop™ was designed for shared hosting configurations that allow access to both secure and insecure web directories from a single server. To utilize a separate secure server, you will need to modify all of the html templates as well as the catalog pages that call the program:

  1. Install the surfshop folder and the ssdata directory on the secure server.
  2. Install a separate images folder on the secure server.
  3. Change all of the <FORM> tags in your catalog pages and templates to call the secure server with an absolute URL:
    https://secure.your-other-server.com/login/surfshop/shop.cgi
  4. Upload any images that are used by your templates to the secure image directory and change all the image tags to reference the secure server:
    <img src="https://secure.your-other-server.com/login/images/picture.gif">
  5. Run autoconfig.cgi on the secure server and enter the SSL paths ONLY. Leave the “non-secure” paths BLANK.

https://secure.your-other-server.com/login/cgi-bin/surfshop/autoconfig.cgi

Example:

   Non-secure path to SurfShop directory:
   Secure Path to SurfShop Directory: secure.your-other-server.com/login/cgi-bin/surfshop 
   Non-secure path to Document Root:
   Secure Path to Document Root: secure.your-other-server.com/login/

My secure server is on the same server, but not the same domain.

This is a common configuration for SSL. Your secure server may be able to access your data files because they reside on the same machine, but cannot run the same scripts because the secure and non-secure directories have not been “symlinked.” Many hosts set it up this way for security reasons. You can either:

  1. Ask your web host to “symlink” the SSL CGI directory to your http CGI directory;
    -or-
  2. Install two separate instances of the SurfShop™ scripts, one in the http CGI directory and one in the https CGI directory.

Run autoconfig.cgi on the secure server and point the program to the ssdata directory you set up on the non-secure server. Complete the installation to make sure that there are no permission issues with the scripts under SSL.

Method Not Allowed or 403 Forbidden

This problem occurs most often when using SSL. If you are certain your scripts are executable (chmod 755), then it is caused by an incorrect configuration in your server's httpd.conf file. Contact your Web host and ask them to set up your directories with CGI execute permissions. Tell them that you are unable to run CGI scripts on your server and that you are receiving “method not allowed” errors.

Software Error

This is the diagnostic message generated by the CGI::Carp module. IF YOU EVER RECEIVE THIS MESSAGE, CONTACT US IMMEDIATELY. It indicates a logic flow or system security problem with the script itself. We will work quickly to resolve any such errors and will deliver upgrades and patches free of charge.

I forgot my password!

If you forget your Administrator username or password, you will have to delete the password file and reconfigure the store using autoconfig.cgi

  1. Using your FTP program, navigate to the private directory in your data directory:
    /[root_directory]/ssdata/1/data/.private
  2. Delete the file named “.p”
  3. Run autoconfig again:
    http://www.your-domain.com/[cgi_location]/surfshop/autoconfig.cgi

Main Page

troubleshooting_and_error_messages.txt · Last modified: 2018/07/03 04:55 (external edit)