Verbose error reporting, Red Hat / Apache

Can I alter the error style using .htaccess?

[ga_ga]

Sorry if this has been asked before, did try browsing & several site searches. I'm getting an unexplained (to me) 500 internal server error on all my perl scripts on my remote hosting at the moment. Host uses Red Hat linux and Apache/2.0.40

The error page I'm getting is a very basic one, just '500 server error' and the OS & Server software, plus a one liner, in this case:

Error message:
Premature end of script headers: whatever.pl

These scripts have been running for years with the same host, no problems, but they did very recently make some changes to their software - not sure what they were using before Red Hat but it was some other form of unix.

ISTR there was a way of getting the server to present more detailed error messages, possibly through .htaccess? Might be wrong.. bit rusty.

I did turn off friendly http error messages in IE6.

Thanks in advance for any help / clues.

[sugarkane]

Inserting this at the beginning of your script (but after the #! line) will send any error messages to your browser:

use CGI::Carp qw(fatalsToBrowser);

That might give you some more info, but only if the programmer has inserted appropriate 'die' lines at possible breaking points.

If *all* your scripts have stopped working after a host upgrade, then the most likely explanation is that the path to perl has changed... check that the first line of your scripts (eg #!/usr/bin/perl ) actually has the correct location of Perl on the server.

[ga_ga]

Thanks sugarkane :)

Verified the path, but that seems okay. On closer inspection it seems that files uploaded before the work was done on the server still work fine - even if they're edited remotely using cute FTP.

Any new files give rise to the inscrutable 500 error with the 'Premature end of script headers' clue.

Tried adding use CGI::Carp qw(fatalsToBrowser); plus die lines to a newly uploaded file, but just got the 500 error back again unfortunately. If I put the same lines (i.e. identical script) in an old perl file (as if using the old filename as nothing more than a 'casing' if you follow).. one that's been on the server since before they did the work, using Cute to remotely edit, it runs fine, very odd

Did wonder if something had slipped with the way I was uploading, i.e. binary versus ASCII, or if I'd forgotten to CHMOD 755, checked this out though & it doesn't seem to be the problem

Judging by the silence, the host is perplexed as well!

[sugarkane]

> files uploaded before the work was done on the server still work fine

Hm. Could be a user/group problem... Do the old & new files belong to the same user and group?

I'm not sure exactly how that could cause problems of the kind you're seeing, but it might be worth looking at...

[ga_ga]

The old & the new files both live in the same /cgi-bin/ on the same hosting account and are chmodded the same, 755, if that would mean they are in the same user & group.

Just received a reply from tech support, they simply said they'd run one of the files on the server & received a syntax error on line 118.. course I couldn't see that with the 500 error being 'in the way'.. fixed it pretty easy, it was just down to a malformed 'if' statement from yesterday - that file now works after a fashion, but it did fail again later on in the script when trying to open some .shtml files in another directory. Tracked *that* down to those files (all 127 of them) having mysteriously chmodded themselves 644. Tried to re-chmod them to 777 (that's how it used to be when it was working, before Red Hat came along), cuteFTP came back with 'chmod command failed'.

Had the bright idea of deleting all those .shtml files, deleting their directory, then recreating their directory & reuploading the .shtml files. Hey presto - chmoddable again, and the script worked fine in terms of being able to open them. However it fell over again, later on in the script, just trying to fill them all with the same garbage string instead of text-database driven content.

Still can't upload any new files & get them to work :( I thought things had been too easy for too long lol.

This is my test code, given that the path to perl seems to be correct, is there anything wrong with it? Runs fine with a pre-existing filename, doesn't if I invent a new filename. Weird!

-------------------
#!/usr/bin/perl
(carriage return)
(carriage return)
print "Content-type: text/html\n\n";
(carriage return)
print "testing.. $ENV{'DOCUMENT_ROOT'}";
(final carriage return)
--------------------

edit <several hours of examining lines of code later>

- got one file working almost perfectly again, changed a subroutine call from

&callSubroutine;

to

&callSubroutine();

This got rid of the garbage output & I have my 127 pages of content back again :-)

Does this look like they've upgraded the version of perl without telling me? not sure how it would cause the problem of old files working and new ones not though.. maybe that's a separate issue.

I'm really guessing here but there couldn't be some kind of thingy on the server that looks for perl files that have been in place since before a version upgrade, and 'diverts' processing of them to a pre-update version for some kind of backwards-compatibility, could there? Yeah okay wacko idea lol. I bet I'm missing one final, incredibly simple thing. My brain hurts. I need a drink ;-)

[ga_ga]

Finally found out what was wrong, got a call from tech support earlier this evening - turns out they've not only updated the Red Hat & the Apache version, my site's actually on a physically new server to boot. Along with everything else, they've updated the FTP software they use... it only had binary transfer enabled (a default security setting I understand, designed to combat DOS attack attempts via ASCII transfer somehow or other). Anyway, my new file uploads were getting forced to binary transfer.

The penny dropped simultaneously.. just as I was going back through the command log in Cute FTP & wondering 'why on earth is it using binary? it's set for ASCII on .pl extensions.. hmm.. I smell a rat..', the 'phone rang.. 'Think I might have found your problem..'

They enabled ASCII transfer on the FTP server software and hey presto.. everything working fine again. I think both myself & the tech support guy were quite relieved, both been mystified over this one!

All's well that ends well :)