From: hoover at gmx dot at
Operating system: Windows Server 2012
PHP version: 7.2.33
Package: *General Issues
Bug Type: Bug
Bug description:Connection handling mod_php and mod_fcgid
Description:
------------
This thing is nearly version independent. The behavior can
be found with 5.4, 7.0 and 7.2.
There are many bug reports for this case but none of them has
a reproducible solution. The bug reports are starting 2005 so
this thing is long lasting.
We have a php-rest-api (no framework) that simplifies a heavy
(java) soap-api.
We have to do a lot of work after the rest/soap-processing. So,
the client of the rest-api gets a response, php should finish
the request and then php should procced with the internal work.
At the point where the client gets the response php should be
aware if client is still alive. So in short:
1) Client - requests
2) PHP - processes
3) PHP - requests soap-server
4) PHP - processes
5) PHP - repsonses to client
6) PHP - should check if client still alive
7) PHP - should close connection to client
8) PHP - processes
9) PHP finished.
So it looks like:
* ignore_user_abort = true
* No use of gzip or ...
* zlib.output_compression = 0
* output_buffering = '0'
* implicit_flush = 1;
* ob_implicit_flush(1);
* Content-Encoding: identity
Functions for connHandling:
connection_aborted()
AND
connection_status()
A) mod_php
A1) If we do a simple echo of the payload and a flush()
the client waits until 9) (until the php-script has total
finished). A client abort, with above functions, is never
detected.
A2) After thousand days of trail and error we noticed that at
least a content-length header has to be set by the php-script
to "release the client". So 7) close connection to client
does work. But again no chance to detect a client abort.
A3) After thousand days of trail and error we noticed that
after a content-length and an echo payload and a flush()
and at least a echo {SPACE} after the flush => detects
a client abort. Analysed with wireshark the {SPACE} fortunately
gets lost in TCP and not sent to the client.
Perfect!
BUT,
B) mod_fcgid
B1) The same thing with mod_fcgid would not work.
It was really hard to find out how connection handling has actually to
be done in this scenario. The php docs are not very helpful here.
Other bug reports are also not very helpful.
So my bug report is at least a question to the php developers:
What is the right and reliable way for connection handling (in
this scenario) wiht mod_php and mod_fcgid?
Regards,
AH
--
Edit bug report at https://bugs.php.net/bug.php?id=79991&edit=1
--
Fix committed: https://bugs.php.net/fix.php?id=79991&r=fixed
Fixed in release: https://bugs.php.net/fix.php?id=79991&r=alreadyfixed
Need backtrace: https://bugs.php.net/fix.php?id=79991&r=needtrace
Need Reproduce Script: https://bugs.php.net/fix.php?id=79991&r=needscript
Try newer version: https://bugs.php.net/fix.php?id=79991&r=oldversion
Not developer issue: https://bugs.php.net/fix.php?id=79991&r=support
Expected behavior: https://bugs.php.net/fix.php?id=79991&r=notwrong
Not enough info: https://bugs.php.net/fix.php?id=79991&r=notenoughinfo
Submitted twice: https://bugs.php.net/fix.php?id=79991&r=submittedtwice
register_globals: https://bugs.php.net/fix.php?id=79991&r=globals
PHP version support discontinued: https://bugs.php.net/fix.php?id=79991&r=phptooold
Daylight Savings: https://bugs.php.net/fix.php?id=79991&r=dst
IIS Stability: https://bugs.php.net/fix.php?id=79991&r=isapi
Install GNU Sed: https://bugs.php.net/fix.php?id=79991&r=gnused
Floating point limitations: https://bugs.php.net/fix.php?id=79991&r=float
No Zend Extensions: https://bugs.php.net/fix.php?id=79991&r=nozend
MySQL Configuration Error: https://bugs.php.net/fix.php?id=79991&r=mysqlcfg