WestHost 500 Internal Server Error

I am stumped - need your help.

[sun818]

Hi, a level 2 tech as WestHost is having a difficult time diagnosing my CGI/Perl script issue. Can one of you geniuses help? Here is the issue:

when I visit /cgi-bin/news/gm.cgi, I get:

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

When the westhost tech support visits the page, he can see it fine.

when I run $ perl gm.cgi from the secure shell login, it ouputs the HTML that I should be seeing.

error-log says:
[error] Premature end of script headers: /cgi-bin/news/gm.cgi

raw-log says:
"GET /cgi-bin/news/gm.cgi HTTP/1.0" 301 314
"GET /cgi-bin/news/gm.cgi HTTP/1.0" 500 601
"GET /cgi-bin/news/gm.cgi HTTP/1.0" 500 601

When I moved an AXS tracking script (from xav.com) it did not work. But when I auto-installed it from xav.com, it worked as expected.

WestHost is running Red Hat Linux using Pentium III servers

Does anyone have an answer or tips on troubleshooting? Think I should rename my .htaccess file?

[sun818]

Figured it out. Learning quick that migrating from a Windows host to Unix host is a lot of work! The following is what I gathered from this move:

1. Having static IPs on former and new host helps with testing.

2. Using explicit URLs, like [domain.com...] can cause problems during a move. Using virtual roots like "/" helps with testing especially with static IPs.

3. Don't assume your FTP client will upload in ASCII unless you explicitly type out "ASCII" before putting files on the remote server. Learned Microsoft FTP.exe is buggy this way.

4. Files are cAsE sensitive on Unix

[EliteWeb]

gm scares me especially with its upload functions for the images. (: I spent many hours setting up that script the first time around. Much of the errors on my behalf was the ftp client transfering in the wrong mode and ending up with ^M GREMLINS ;P

[sun818]

^M GREMLINS

Gremlins, I like that! :) Yeah, that was the issue. The "vi" command in Red Hat Linux will not show carriage returns (CR, 0D) for some reason.

[dingman]

The "vi" command in Red Hat Linux will not show carriage returns (CR, 0D) for some reason.

If you don't know yet, it might serve you well to be aware that Unix and DOS/Windows machines have slightly different formats for text files. On Windows, lines in a text file end with 0x0d, 0x0a (cr, lf). In Unix, they end in just 0x0a. If I remember right, Mac text files end lines with just 0x0d. Web browsers, of course, are all smart enough to deal with this issue when they get a file and display a multi-line text file as a multi-line text file no matter what line-end convention it uses. (Distressingly, NN4 alters spacing in rendered HTML depending on whether and what kind of line-end there may be between tags. It's really annoying.) Editors vary in their support for non-native end-of-line conventions. Notepad sucks - it sees non-Windows text files as all one line, with a funny-looking square each time there should be a new line. Emacs just transparently switches to writing the file in whatever style it found it. I have no idea what vi does. In Unix editors that have the same cluelessness as Notepad, you get lines that end with ^M ( == 0x0d), because the 0x0d is seen as its own character, not part of the newline.

Most unix hosts will have a program called 'dos2unix' installed that you can use to convert files from one Windows format to Unix format. You could also try using ASCII mode in an FTP transfer rather than binary for the text and HTML files.

[sun818]

Thanks dingman. It was my mistake to assume

vi

worked the same in all flavors of Unix. My little Unix experience is with an old version of Solaris.

'dos2unix'

- Unfortunately westhost does not make this available.

ASCII mode in an FTP transfer

- Heh, I just added .cgi and .pl to the list of ASCII file types in LeechFTP, so I should be fine from now on. Phew! :)