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

["J.H." <warthog9@eaglescrag.net>]

> 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