?

Log in

No account? Create an account
avatar

My life as journaled

Because I'm boring like that


Previous Entry Share Next Entry
avatar

MQP, good and bad.

The good news:
M, the partner who appeared to simply be shirking and dumping his work on other people, had a good reason: the reason he couldn't get his cgi code to run was not his fault.

The bad news:
I have no idea why any cgi code we try to run gives an internal server error. Old cgi stuff works fine, but anything new doesn't. Even if new stuff is two lines which we know should work, it still gives a 500 (internal server error). And so far, the webmaster people have not been overly helpful (i.e. pointing out errors in the code that exist, but should not have caused this error).
Tags:

  • 1

Debuging CGIs

ctriv March 20th, 2003
Remember, debuging a CGI is an art form, not a science. The best way to handle it is to do error handling that will always give headers to the server so you can print your error message out nicely. In the perl world, CGI::Carp's fatalsToBrowser option will do this for you.

Re: Debuging CGIs

anitra March 20th, 2003
Problem is, it has to be in something I can't fix. Because even this:


#!/usr/local/bin/perl
print "Content-type:text/html\n\n";
print "<HTML><BODY>Testing.... Hello World</BODY></HTML>";

gives a 500 Internal Server Error.

(Only thing I've changed above is the <s and >s, so they would show up.)

Update

anitra March 20th, 2003
OK, so M's not so blameless after all. Apparently, the whole problem was caused because of ......... PC-style carriage returns in the new code.

That's right, I spent more than 2 hours talking with the webmaster and beating my head against the wall because my partner doesn't know that he shouldn't compose UNIX code in Notepad.

lizesc March 22nd, 2003
So not our fault. You never told me I was trouble shooting something he develops in windows...

  • 1