Ticket #998 (closed defect: fixed)

Opened 1 year ago

Last modified 10 months ago

fastcgi prints an additional empty line for each packet of type FCGI_STDERR

Reported by: carenas@sajinet.com.pe Assigned to: jan
Priority: normal Milestone:
Component: mod_fastcgi Version: 1.4.13
Severity: minor Keywords:
Cc: Blocking:
Need Feedback: 0

Description

every time a fastcgi script writes an error using (for example for the C API) :

FCGX_FPrintF(err, "This is an error message");

2 packets of type FCGI_STDERR are generated (the first one containing the message and the second one of length 0), but lighttpd print both generating an empty lane as shown by (from the errorlog) :

2007-01-27 23:13:02: (mod_fastcgi.c.2519) FastCGI-stderr: This is an error message 2007-01-27 23:13:02: (mod_fastcgi.c.2519) FastCGI-stderr:

attached patches for lighttpd-1.4.x and trunk with a fix that uses the same logic applied for packets of type FCGI_STDOUT

Attachments

lighttpd-1.4.x-fastcgi-quiet-error.patch (423 bytes) - added by carenas@sajinet.com.pe on 01/28/2007 07:32:42 AM.
patch for lighttpd 1.4.x's mod_fastcgi to skip printing empty error packets
lighttpd-fastcgi-quiet-error.patch (369 bytes) - added by carenas@sajinet.com.pe on 01/28/2007 07:39:14 AM.
patch for lighttpd 1.5 (trunk)'s mod_fastcgi to skip printing empty error packets

Change History

01/28/2007 07:32:42 AM changed by carenas@sajinet.com.pe

  • attachment lighttpd-1.4.x-fastcgi-quiet-error.patch added.

patch for lighttpd 1.4.x's mod_fastcgi to skip printing empty error packets

01/28/2007 07:39:14 AM changed by carenas@sajinet.com.pe

  • attachment lighttpd-fastcgi-quiet-error.patch added.

patch for lighttpd 1.5 (trunk)'s mod_fastcgi to skip printing empty error packets

01/28/2007 10:00:48 AM changed by carenas

in lighttpd 1.5 the implementation used for mod_proxy_backend_fastcgi doesn't show this problem as shown in :

mod_proxy_backend_fastcgi.c.476: (trace) (fastcgi-stderr) this is an error message
mod_proxy_backend_fastcgi.c.476: (trace) (fastcgi-stderr) this is an error message

01/28/2007 02:41:08 PM changed by carenas

a fastcgi program using the fcgi_stdio emulation is shown below:

#include "fcgi_config.h"
#include "fcgi_stdio.h"

int main()
{
   while (FCGI_Accept() >=0) {
      printf("Content-type: text/html\r\n");
      printf("\r\n");
      printf("This is some content");
      fprintf(stderr, "This is some error");
   }
   return 0;
}

a fastcgi C program using the native API :

#include "fcgi_config.h"
#include "fcgiapp.h"

int main()
{
   FCGX_Stream *in, *out, *err;
   FCGX_ParamArray envp;

   while (FCGX_Accept(&int, &out, &err, &envp) >= 0) {
      FCGX_FPrintF(out, "This is some content");
      FCGX_FPrintF(err, "This is some error");
   }

   return 0;
}

01/30/2007 12:30:35 AM changed by Elan Ruusamäe <glen@delfi.ee>

this patch however doesn't solve problem with PHP-FCGI error logs:

2007-01-30 02:26:31: (mod_fastcgi.c.2504) FastCGI-stderr: error

2007-01-30 02:26:37: (mod_fastcgi.c.2504) FastCGI-stderr: error

2007-01-30 02:26:38: (mod_fastcgi.c.2504) FastCGI-stderr: error
$ cat z.php
tore
<?

error_log("error");

01/31/2007 11:19:51 AM changed by carenas

the problem with PHP is a bug in PHP not in lighttpd or fastcgi as error_log is printing a an extra "CRLF" at the end of the message

http://bugs.php.net/bug.php?id=31472

interestingly enough though this patch "fixes" the problem by redirecting stderr into the log file as can be seen if instead the following script is used :

<?php
  $stderr = fopen("php://stderr", "w");
  fputs ($stderr, "error\n");
  fclose ($stderr);
?>

02/05/2007 01:16:22 PM changed by glen

applied in [1606] and [1607].

02/05/2007 01:21:27 PM changed by glen

  • status changed from new to closed.
  • resolution set to fixed.

09/06/2007 08:02:16 AM changed by glen

  • blocking changed.
  • pending changed.

Add/Change #998 (fastcgi prints an additional empty line for each packet of type FCGI_STDERR)




Change Properties
Action