500 Internal Server Error - with a twist

[timd]

I kept getting 500 Internal Server Errors when trying to set up one of my Perl scripts, so I decided to test a simple "Hello World!" script. It produced the same error:

Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.

I've uploaded the file in ASCII, I've set the permissions to 755, I've connected to the server with ssh and verified the path to Perl. None of that fixed the problem. The strangest part is when I try to run the script while I've connected with ssh is that it works:

$ ./test.cgi
Content-type:text/html

Hello world! This CGI / PERL script is working properly!
$

Does anyone have any ideas why I can't get even the "Hello World!" script to run on my web site? Thanks for your help.

[Comatose]

post the hello world code

[trickykid]

post the hello world code

This wouldn't be a problem with the script since it runs fine from the command but a misconfiguration of apache or whatever webserver you are using.

[MattEvans]

my webserver's well wierd, i have a cpanel frontend i can login to plus various ftp clients on my pc; if i upload a perl script and set the permissions correct i get a 500 error, if i overwrite a working perl script (using ActiveState Komodo) i get a 500 error (of course i check the permissions afterwards!) if i upload a file then change the permissions using cpanel, guess what! i get a 500 error.

infact, the only way i can get a perl script up, is to use my cpanel to create a new perl file, then set the permissions, then overwrite the contents of the file; but only in cpanel.

what's with that?! :eek:

[KevinADC]

make sure you are uploading the file in ASCII (text) format and not binary format.

[MattEvans]

make sure you are uploading the file in ASCII (text) format and not binary format.

Hm; using Windows XP FTP you don't have a choice, and the files always read as ASCII when I view at them. Would I see a visible difference (in the file contents) if it was uploaded in binary mode? Surely there'd only be a problem uploading binary-type files as ASCII?

Komodo's remote save should certainly be ASCII though!

Loading an ftp client other than Windows XP is as much of an inconvenience as opening up cpanel..

It seems arbitrary sometimes; I've had success with XP FTP sometimes, and Komodo remote save sometimes : but the only way at the moment that I can guarantee 500 errors arent a result of my own mistakes is to create the files in cpanel and overwrite the contents...

It took me hours to figure out that that would work. Certainly seems strange!

[KevinADC]

I would at least try using an FTP client to eliminate if XP FTP is the problem or not.

[Puckdropper]

With XP's FTP client, you have a choice. Use "binary" or "ascii" to set the mode. (See also: http://www.uncreativelabs.net/howtos/ftp.htm (Yes this is a plug.))

Also, are you trying to run your "Hello World" script on the web server side in the cgi-bin directory? Once I put the file in cgi-bin and set permissions, it ran fine.

http://puckdroppers.us/cgi-bin/test.pl

--

For the record I'm new to Perl, about furthest I've gotten is declaring my intent to learn it and giving a few reasons why.

[KevinADC]

This wouldn't be a problem with the script since it runs fine from the command but a misconfiguration of apache or whatever webserver you are using.

I missed your post somehow so I realize this is a late reply. The problem could very well be the script. If run as a CGI it needs to print an http header before trying to print anything else. This is not a problem from the command line and will work, but will error out with a 500 ISE if initiated as a CGI script from a browser.

[sut]

After you have created a working copy with cpanel and overwritten it with your code, do

cat -v test.pl

Then rename that file.

mv test.pl goodtest.pl

Then upload so you get the 500 error and do the cat again.

cat -v test.pl

Then diff them.

diff test.pl goodtest.pl

And post all output here.

I think the upload is messing with your output. I'm betting on the DOS EOL is corrupting the "Content-type: text/html" string into "Content-type: text/html^M"

[TysonDude]

I had this same problem. I used a program called EditPlus and it created the same problem for me. I never could solve it with EditPlus, but I have figured it out in Komodo.

Perhaps you have already figured this out or don't need a solution any more, but I wanted to post my solution here in case anyone else stumbles across this post. Hopefully it will help you out.

I believe the cause is Windows adding in line breaks. Since these line breaks are invisible in editors, there are no apparent problems. But when the compiler attempts to run the program, an internal server error occurs.

Here is what I did:
1. With the file open, select "Edit => Current File Settings..."
2. Next to Line Endings, change "DOS/Windows (\r\n)" to "UNIX (\n)"
3. Unclick the box next to "Preserve existing line endings"
4. Reupload (remote save) the file

This should hopefully solve your problem, as it did mine.

[lordspace]

a nice trick is to use this:

use CGI::Carp qw(fatalsToBrowser);

[TysonDude]

a nice trick is to use this: use CGI::Carp qw(fatalsToBrowser);

This is definately helpful code, but it unfortunately does not help in this scenario. I believe it is because the line breaks cause the error before the program can be compiled.

[KevinADC]

Nearly all FTP applications silently convert the line endings when you upload a file from a local computer to a remote computer. So if you upload from windows to Unix or Linux there should be nothing to worry about. You should upload in ASCII (text) mode though for text files.

Some FTP applications you choose the remote computer type from a list and some do the checking automatically and convert the line endings as needed.