php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #68207 Setting fastcgi.error_header can result in an E_WARNING being triggered
Submitted: 2014-10-10 14:07 UTC Modified: 2022-11-21 14:06 UTC
Votes:1
Avg. Score:3.0 ± 0.0
Reproduced:0 of 0 (0.0%)
From: nj506 at zepler dot net Assigned: bukka (profile)
Status: Closed Package: FPM related
PHP Version: 5.5.17 OS:
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: nj506 at zepler dot net
New email:
PHP Version: OS:

 

 [2014-10-10 14:07 UTC] nj506 at zepler dot net
Description:
------------
With fastcgi.error_header set to some value (e.g. "HTTP/1.1 500 Internal Server Error"), PHP-FPM will attempt to set the header value when the PHP exit status is determined to be 255 - https://github.com/php/php-src/blob/f89ee8040a8b8d93981c9df85a79592ceac02f1f/sapi/fpm/fpm/fpm_main.c#L1950-L1958

If headers have already been sent, then an E_WARNING is triggered by sapi_header_op - https://github.com/php/php-src/blob/f89ee8040a8b8d93981c9df85a79592ceac02f1f/main/SAPI.c#L675-L686

As such, if headers have been sent (e.g. due to output), then at some point PHP sets the exit_status value to 255 (e.g. due to an error), and fastcgi.error_header is set to some value, then an E_WARNING will be triggered.

This seems undesirable - perhaps it should simply not attempt to call sapi_header_op if headers have already been sent?

Test script:
---------------
<?php

// With fastcgi.error_header set to "HTTP/1.1 500 Internal Server Error"

echo 'x';

register_shutdown_function(function() {
    file_put_contents('/tmp/error', print_r(error_get_last(), true));
});

z(); // trigger a fatal error

Expected result:
----------------
A fatal error will be triggered, and the last error visible when shutting down will be the fatal.

e.g.

$ cat /tmp/error
Array
(
    [type] => 1
    [message] => Call to undefined function z()
    [file] => .../test.php
    [line] => 7
)

Actual result:
--------------
PHP-FPM attempts to replace the header, but headers have already been sent (due to output):

$ cat /tmp/error
Array
( 
    [type] => 2
    [message] => Cannot modify header information - headers already sent by (output started at test.php:3)
    [file] => Unknown
    [line] => 0
)

Patches

Pull Requests

Pull requests:

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2022-11-21 14:01 UTC] bukka@php.net
The following pull request has been associated:

Patch Name: Fix bug #68207: Setting fastcgi.error_header can result in a WARNING
On GitHub:  https://github.com/php/php-src/pull/9980
Patch:      https://github.com/php/php-src/pull/9980.patch
 [2022-11-21 14:06 UTC] bukka@php.net
-Status: Open +Status: Assigned -Assigned To: +Assigned To: bukka
 [2022-11-21 14:06 UTC] bukka@php.net
Apology for more than 8 years of silence. Seems like the reported example actually works (at least on PHP 8) as FPM flushes headers at the end of request. There is an edge case with fastcgi_finish_request() which I fixed in the linked PR so it will no longer emits any headers sent warning.

During this investigation I also noticed another problem with fastcgi.error_header which I create an issue for: https://github.com/php/php-src/issues/9981
 [2022-11-22 18:22 UTC] git@php.net
Automatic comment on behalf of bukka
Revision: https://github.com/php/php-src/commit/5a4520bc2bc1698c4e7d1dc19956ce5519331e02
Log: Fix bug #68207: Setting fastcgi.error_header can result in a WARNING
 [2022-11-22 18:22 UTC] git@php.net
-Status: Assigned +Status: Closed
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Nov 21 14:01:29 2024 UTC