Development

#3191 ([PATCH] Duplicate Status Headers crashes FastCGI during Symfony 404 errors)

You must first sign up to be able to contribute.

Ticket #3191 (closed defect: fixed)

Opened 5 years ago

Last modified 4 years ago

[PATCH] Duplicate Status Headers crashes FastCGI during Symfony 404 errors

Reported by: corporealfunk Assigned to: fabien
Priority: major Milestone: 1.0.22
Component: controller Version: 1.1.0
Keywords: fastcgi controller status headers erorr 404 Cc:
Qualification: Unreviewed

Description

This ticket is the same issue posted on the user forum here:

http://www.symfony-project.org/forum/index.php/t/11760/

In a fastCGI environment when symfony (versions 1.0.9 - 1.0.11) attempts to output the rendered symfony 404 error page, two HTTP "Status" headers are output from the framework, like so: 

HTTP/1.0 404 Not Found
Status: 404

This does not seem viable in a fastCGI environment and fastCGI throws up a 500 error and reports to Apache:

FastCGI: comm with server "/var/www/eyepaste/cgi-bin/php5.fcgi" aborted: error parsing headers: duplicate header 'Status'

A work-around (as I posted in the forum) is to simply comment out the duplicate status header code in the sfController class, line 260, so sfController.class.php:260 becomes: 

 //$this->getContext()->getResponse()->setStatusCode(404);

This fixes the problem in this instance. (see attached patch)

Please note that this ticket is not a duplicate of ticket #669 which is dealing specifically with "Location: xxxxxxx" 302 redirects (but with the same symptom).

More information about the tested environments: 

symfony 1.0.9 - 1.0.11
apache 2.2.3
suexec wrapper enabled and disabled (both fail)
fastcgi 2.5.x
php5 (5.2.0 - 5.2.5 as a cgi)
debian etch 4.0

Attachments

sfController.diff (0.6 kB) - added by corporealfunk on 03/24/08 17:19:09.
diff patch to fix fastcgi error 404 status headers

Change History

03/24/08 17:19:09 changed by corporealfunk

  • attachment sfController.diff added.

diff patch to fix fastcgi error 404 status headers

(in reply to: ↑ description ) 08/04/08 09:33:31 changed by sercba

I have the same problem. I do not know to speak very well English.

In spanish:

Tengo el mismo problema, me ha llevado mucho tiempo llegar aquí. He modificado el código, pero es posible que lo incluyan en alguna revisión?

08/18/08 23:52:27 changed by juliannoble

  • priority changed from minor to major.
  • version changed from 1.0.11 to 1.1.0 RC2.

This is still causing fastcgi troubles in symfony version 1.1.1

Contrary to the patch above, I belive it is the setHttpHeader line that should be removed.

$this->context->getResponse()->setStatusCode(404);

Should be retained, because in sfWebResponse's sendHttpHeaders it becomes: $status = 'HTTP/1.1 '.$this->statusCode.' '.$this->statusText;

From various postings on the php bug list from php.net addresses - it seems that sending header('HTTP/1.x xxx reason') is the SAPI independent way to send a status code.

In other words, PHP will automatically output that as a 'Status: xxx reason' header if it is running in cgi mode.

I can't see any circumstances under which it is legitimate to set them both - so can we please get this fixed?

10/24/08 14:24:39 changed by onjin

I make this work by patching sfResponse class 

Index: lib/response/sfWebResponse.class.php
===================================================================
--- lib/response/sfWebResponse.class.php	(wersja 3398)
+++ lib/response/sfWebResponse.class.php	(kopia robocza)
@@ -271,6 +271,12 @@
     // headers
     foreach ($this->getParameterHolder()->getAll('symfony/response/http/headers') as $name => $value)
     {
+
+      // fix for duplicated header 'Status' in (f|fast)cgi mode
+      if (substr(php_sapi_name(), 0, 3) == 'cgi' && strtolower($name) == 'status')
+      { continue; }
+
+
       header($name.': '.$value);
 
       if (sfConfig::get('sf_logging_enabled') && $value != '')

this patch prevents to send Status header in cgi mode, just HTTP 1/x <status> will be sent.

10/24/08 14:26:23 changed by onjin

sorry, i mean sfWebResponse (not sfResponse)

10/31/08 16:17:01 changed by mrhyde

bug still exists in 1.0.19 version. any chances to fix this?

11/04/08 11:28:59 changed by mrhyde

this is my workaround for those who cannot wait for symfony fix (version 1.0): 

<?php
class myWebResponse extends sfWebResponse
{
  /**
   * Sets a HTTP header. Workaround of http://trac.symfony-project.org/ticket/3191
   *
   * @param string HTTP header name
   * @param string Value
   * @param boolean Replace for the value
   *
   */
  public function setHttpHeader($name, $value, $replace = true)
  {
    if (strtolower($name) != 'status')
    {
      parent::setHttpHeader($name, $value, $replace);
    }
  }
}

and add to config/factories.yml 

all:
  response:
    class: myWebResponse

11/06/08 08:55:16 changed by fabien

  • milestone set to 1.1.5.

06/05/09 09:37:51 changed by nicolas

  • version changed from 1.1.0 RC2 to 1.1.0.
  • milestone changed from 1.1.8 to 1.3.0.

10/13/09 00:56:24 changed by Kris.Wallsmith

  • milestone changed from 1.3.0 alpha2 to 1.3.0 beta1.

11/15/09 20:54:59 changed by FabianLange

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

(In [23984]) [1.0, 1.2, 1.3, 1.4] not setting status header for servers in cgi-sapi mode (fixes #3191)

11/15/09 20:56:08 changed by FabianLange

  • milestone changed from 1.3.0 RC1 to 1.0.22.