Skip to content

Releases: PHPFastCGI/FastCGIDaemon

Release 0.11.0

14 Aug 08:58
f9b674b
Compare
Choose a tag to compare

Bugfix: Large POST requests failing

01 Mar 11:50
7bbda73
Compare
Choose a tag to compare

Issue: #30
PR: #31

Also includes fixes to the CI system #32

Auto Shutdown Functionality

01 Dec 21:06
Compare
Choose a tag to compare

Added a command line flag for gracefully shutting down the daemon after a 5XX error code is received.

Flag shutdown functionality

01 Dec 18:54
Compare
Choose a tag to compare

Applications have always been able to throw a shutdown exception to trigger a graceful shutdown, however it's not possible to respond to a request and gracefully shutdown.

These new shutdown methods allow the user to respond to the request whilst flagging the daemon for a graceful shutdown without disturbing the response.

Support for Symfony 3.0

23 Mar 09:36
Compare
Choose a tag to compare

Changes to the dependency file to allow for Symfony 3.0 versions of components.

Structural improvements, introduction of drivers, configuration and resource limits

20 Oct 21:59
Compare
Choose a tag to compare
v0.7.0

Improved handling of internal errors on userland daemon

Bugfix: [major] Fixed issue reading params records

29 Aug 12:57
Compare
Choose a tag to compare

FIxes

  • FastCGI specification allows for multiple name-value pairs to be sent inside a params record. Apache mod_fastcgi doesn't do this, but nginx does. This behaviour is now being accounted for.

Improvements

  • General code clean up and refactoring inside connection handler

Bugfix: Possible null return values in Request::getPost() and Request::getQuery()

26 Aug 23:09
Compare
Choose a tag to compare

Fixes

  • The possibility of a NULL return value from getPost() and getQuery() on the FastCGI request object has now been eliminated. This could have caused an issue with the Zend Diactoros library.

Core optimisation, introduction of generic FastCGI request object

26 Aug 22:03
Compare
Choose a tag to compare

After profiling the application under load it became clear that one of the bottle necks slowing down the performance was the instantiating of the PSR-7 server request message objects. It is possible that using a library other than Zend Diactoros to create these objects would have increased the performance of the daemon, however possibly at a quality cost. In the case of the adapters to the Symfony and Silex framework, it made no sense having them tuned to PSR-7 server request message objects, only for them to be converted to the corresponding HttpFoundation object before being consumed. As the message received by the FastCGI daemon is simple, it makes far more sense to leave this message in an object that represents the state and format it was received in - and then provide the functionality for alternative representations if required.

As a result, the KernelInterface has now changed to accept only FastCGI request objects (but methods exist on these objects to create PSR-7 or HttpFoundation objects). The KernelInterface can return either PSR-7 or HttpFoundation responses.

Suppressed warnings from failed stream_socket_accept()

20 Aug 09:31
Compare
Choose a tag to compare

FastCGIDaemon v0.5.3

Fixes

  • Suppressed stream_socket_accept warnings. Was getting: "stream_socket_accept(): accept failed: Resource temporarily unavailable" despite waiting until a read was ready using stream_select. This only happened using mod_fastcgi on Apache with multiple processes (rather than one worker). It looks as if the connections were closed before they could be accepted - from the client side, all of the requests were answered correctly without server errors so I'll suppress these warnings for now.