Download the PHP package hollodotme/fast-cgi-client without Composer

Fast CGI Client

A PHP fast CGI client to send requests (a)synchronously to PHP-FPM using the FastCGI Protocol.

This library is based on the work of Pierrick Charron's PHP-FastCGI-Client and was ported and modernized to latest PHP versions, extended with some features for handling multiple requests (in loops) and unit and integration tests as well.

This is the documentation of the latest release.

Please have a look at the backwards incompatible changes (BC breaks) in the changelog.

Please see the following links for earlier releases:

• PHP >= 7.0 (EOL) v1.0.0, v1.0.1, v1.1.0, v1.2.0, v1.3.0, v1.4.0, v1.4.1, v1.4.2
• PHP >= 7.1 v2.0.0, v2.0.1, v2.1.0, v2.2.0, v2.3.0, v2.4.0, v2.4.1, v2.4.2, v2.4.3, v2.5.0, v2.6.0, v2.7.0, v2.7.1, v2.7.2, v3.0.0-alpha, v3.0.0-beta, v3.0.0, v3.0.1, v3.1.0, v3.1.1, v3.1.2, v3.1.3, v3.1.4, v3.1.5

Read more about the journey to and changes in v2.6.0 in this blog post.

You can find an experimental use-case in my related blog posts:

• Experimental async PHP vol. 1
• Experimental async PHP vol. 2

You can also find slides of my talks about this project on speakerdeck.com.

Installation

Usage - connections

This library supports two types of connecting to a FastCGI server:

1. Via network socket
2. Via unix domain socket

Create a network socket connection

Create a unix domain socket connection

Usage - single request

The following examples assume that the content of /path/to/target/script.php looks like this:

Send request synchronously

Send request asynchronously (Fire and forget)

Read the response, after sending the async request

Notify a callback when async request responded

You can register response and failure callbacks for each request. In order to notify the callbacks when a response was received instead of returning it, you need to use the waitForResponse(int $socketId, ?int $timeoutMs = null) method.

Usage - multiple requests

Sending multiple requests and reading their responses (order preserved)

Sending multiple requests and reading their responses (reactive)

Sending multiple requests and notifying callbacks (reactive)

Reading output buffer from worker script using pass through callbacks

It may be useful to see the progression of a requested script by having access to the flushed output of that script. The php.ini default output buffering for php-fpm is 4096 bytes and is (hard-coded) disabled for CLI mode. (See documentation) Calling ob_implicit_flush() causes every call to echo or print to immediately be flushed.

The callee script could look like this:

The caller than could look like this:

Requests

Requests are defined by the following interface:

Alongside with this interface, this package provides an abstract request class, containing default values to make the API more handy for you and 5 request method implementations of this abstract class:

• hollodotme\FastCGI\Requests\GetRequest
• hollodotme\FastCGI\Requests\PostRequest
• hollodotme\FastCGI\Requests\PutRequest
• hollodotme\FastCGI\Requests\PatchRequest
• hollodotme\FastCGI\Requests\DeleteRequest

So you can either implement the interface, inherit from the abstract class or simply use one of the 5 implementations.

Default values

The abstract request class defines several default values which you can optionally overwrite:

Request contents

In order to make the composition of different request content types easier there are classes covering the typical content types:

• UrlEncodedFormData
• MultipartFormData
• JsonData

You can create your own request content type composer by implementing the following interface:

ComposesRequestContent

Request content example: URL encoded form data (application/x-www-form-urlencoded)

This example produces the following $_POST array at the target script:

Request content example: multipart form data (multipart/form-data)

Multipart form-data can be used to transfer any binary data as files to the target script just like a file upload in a browser does.

PLEASE NOTE: Multipart form-data content type works with POST requests only.

This example produces the following $_POST and $_FILES array at the target script:

Request content example: JSON encoded data (application/json)

This example produces the following content for php://input at the target script:

Responses

Responses are defined by the following interface:

Assuming /path/to/target/script.php has the following content:

The raw response would look like this:

Please note:

• All headers sent by your script will precede the response body
• There won't be any HTTP specific headers like HTTP/1.1 200 OK, because there is no webserver involved.

Custom headers will also be part of the response:

The raw response would look like this:

You can retrieve all of the response data separately from the response object:

Trouble shooting

"File not found." response (php-fpm)

This response is generated by php-fpm for the preceding error Primary script unknown in case the requested script does not exists or there are path traversals in its path like /var/www/../run/script.php.

Although the given path may exist and would resolve to an absolute path in the file system, php-fpm does not do any path resolution and accepts only absolute paths to the script you want to execute.

Programatically you can handle this error like this:

Prepare local development environment

This requires docker and docker-compose installed on your machine.

make update

Run examples

make examples

Run all tests

make tests

Command line tool (for local debugging only)

Please note: bin/fcgiget is not included and linked to vendor/bin via composer anymore since version v3.1.2for security reasons. Read more.

Run a call through a network socket:

docker-compose exec php74 php bin/fcgiget localhost:9001/status

Run a call through a Unix Domain Socket

docker-compose exec php74 php bin/fcgiget unix:///var/run/php-uds.sock/status

This shows the response of the php-fpm status page.