> Hmm... anuthing that happens after 'use CGI::Carp;' is parsed should > have STDERR redirected to web server logs, see CGI::Carp manpage > > [...] > > use CGI::Carp > > And the standard warn(), die (), croak(), confess() and carp() calls will > automagically be replaced with functions that write out nicely time-stamped > messages to the HTTP server error log. > > [...] > > REDIRECTING ERROR MESSAGES > > By default, error messages are sent to STDERR. Most HTTPD servers direct > STDERR to the server's error log. > > [...] > > Especially the second part. That was not what I was seeing, so either something I was doing was horking how CGI::Carp works, or their claim that "most HTTPD server direct STDERR to the server's error log" is false. > Could you give us example which causes described misbehaviour? While I was working on the trapping of the error pages I started getting 500 errors when going to a non-existent sha1. Running the command from the cli revealed that a message from a git command was making it out to the console. Redirecting STDERR masked the error from git, and stopped premature data being sent out before the headers were sent. > I have nothing against this patch: if you have to have it, then you > have to have it. I oly try to understand what might be core cause > behind the issue that this patch is to solve... I've re-tried this, if you remove this patch and attempt to visit a non-exist sha1, *boom* I can only speculate that CGI::Carp only redirects the output inside of perl, and does not handle the case when called programs (like git) write more directly to STDERR. - John 'Warthog9' Hawley -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html