php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #69414 Script hangs forever
Submitted: 2015-04-10 01:39 UTC Modified: 2017-10-24 06:34 UTC
Votes:2
Avg. Score:4.0 ± 1.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: deivid dot garcia dot garcia at gmail dot com Assigned:
Status: Open Package: Output Control
PHP Version: 5.6.7 OS: IIS 8.5
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: deivid dot garcia dot garcia at gmail dot com
New email:
PHP Version: OS:

 

 [2015-04-10 01:39 UTC] deivid dot garcia dot garcia at gmail dot com
Description:
------------
I've been experiencing for a very long time IIS spinning UP hundreds of fast-cgi processes, rendering the server unusable.

Today I came across this situation that seems related to IIS spinning up so many instances.

In Drupal, thumbnail generation is done on the fly. The Conent-Length headers are sent before sending the file to the client, but if anything fails during this process, the client will remain endlesly connected (waiting for the rest of the response) even if the script has finished or exit() has been called.

It looks like the fast-cgi processes are not released until they time out, even if exit() was called. Because IIS thinks these processes are busy, it spins up new processes (depending on the MAX setting in IIS) or makes new requests wait until the locked fast-cgi processes have been freed.

I'm not an HTTP protocol expert, but there must be some way for PHP to tell the client that there's nothing else to wait for because the script has already finished execution.

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

header('Content-Length: 2838');

// Something went wrong while preparing the output data
// so send a 500 and exit
header('Status: 503 Service Unavailable');
print 'Custom message';
exit(500);

Expected result:
----------------
Expect to see the 'Custom Message' in the browser inmediately, instead of the client timing out and holding the fast-cgi process hostage until it times out.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2015-04-11 17:18 UTC] laruence@php.net
-Assigned To: +Assigned To: mike
 [2015-04-13 15:04 UTC] mike@php.net
I doubt that this is really an "Output Control" problem wrt output.c, but I'll have a look anyway.

I'd rather think this is a problem with the web server waiting for "Content-Length" bytes to arrive from the FCGI backend. Nevertheless, this should be handled in the FCGI code, if it isn't already, though, and I'll try to reproduce with another web server.
 [2017-10-24 06:34 UTC] kalle@php.net
-Status: Assigned +Status: Open -Assigned To: mike +Assigned To:
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Apr 20 14:01:29 2024 UTC