Re: [PATCH 16/18] gitweb: When changing output (STDOUT) change STDERR as well

From: J.H. <warthog9@eaglescrag.net>
Date: Dec 12, 2010, 05:25 UTC
Message-ID: <4D045CD6.9060806@eaglescrag.net>
In-Reply-To: <m3vd32z9yk.fsf@localhost.localdomain>

Show 21 quoted lines

> 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