# Buzz: a lightweight PHP HTTP client with three backends

> Buzz is a compact PHP HTTP client built around PSR-7 messages and PSR-17 factories. Its three backends cover simple requests, cURL-based requests, batches, and HTTP/2 server push, while its narrow feature scope favors stability over expansion.

**kriswallsmith/Buzz** — PHP's lightweight HTTP client

- Repository: https://github.com/kriswallsmith/Buzz
- Stars: 1,916 · Forks: 247
- Language: PHP
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/kriswallsmith-buzz

## What problem Buzz solves for PHP applications

Buzz addresses the need to send HTTP requests from PHP without adopting a large HTTP client stack. The README positions it as a lightweight library for issuing requests, with a browser-like API intended to make scripted HTTP behavior easier to use in tests and small applications.

Its scope is deliberately limited. The project describes the implementation as fewer than 1,000 lines of code and says that Buzz covers 90% of common HTTP use cases. This is a useful boundary for evaluation. Buzz is aimed at developers who need predictable request sending, PSR-compatible messages, and several transport choices, not at teams looking for an extensive middleware and integration catalog.

The library is relevant to PHP command-line tools, internal services, libraries that call remote APIs, and applications that make conventional `GET` or other HTTP requests. It can serve both a higher-level `Browser` interface and lower-level client classes. Projects that require extensive transport configuration, built-in retry policies, or many optional integrations should assess those requirements separately because the README does not document such a feature set.

## How Buzz handles requests and PSR messages

Buzz provides three clients: `FileGetContents`, `Curl`, and `MultiCurl`. The `FileGetContents` client is the simplest documented entry point. It is constructed with a PSR-17 response factory, while `Browser` receives that client and a PSR-17 request factory. The browser then creates and sends requests through the selected client.

The returned response is a PSR-7 response. This means the application can read its status code, headers, and body through standard PSR-7 methods rather than relying on a separate Buzz response type. `Browser::getLastRequest()` exposes the request used by the latest browser operation, which is useful when an application needs to inspect the outgoing message.

The lower-level API accepts a prepared PSR-7 request and an options array. The README shows a `timeout` option passed to `sendRequest()`. This design keeps message construction separate from transport selection. It also means that the application must install a compatible PSR-17 implementation, since Buzz does not provide the factory used in the examples itself.

## Installing Buzz and making a first request

The README gives Composer as the installation route. Buzz requires a PSR-17 request and response factory implementation, and it names `nyholm/psr7` as one example. Install both packages with:

```bash
composer require kriswallsmith/buzz
composer require nyholm/psr7
```

The first browser-level request can use the same `Psr17Factory` for requests and responses. This replaces the README's placeholder factory names with the concrete package selected for the example.

```php
use Buzz\Browser;
use Buzz\Client\FileGetContents;
use Nyholm\Psr7\Factory\Psr17Factory;

$client = new FileGetContents(new Psr17Factory());
$browser = new Browser($client, new Psr17Factory());
$response = $browser->get('https://www.google.com');

echo $browser->getLastRequest()."\n";
echo $response->getStatusCode();
```

The response exposes the status code through PSR-7. The example does not guarantee a particular status because it sends a request to a remote service. For an application that already has a request object, the lower-level client provides a direct path:

```php
use Buzz\Client\FileGetContents;
use Nyholm\Psr7\Factory\Psr17Factory;
use Nyholm\Psr7\Request;

$request = new PSR7Request('GET', 'https://google.com/foo');
$client = new FileGetContents(new Psr17Factory());
$response = $client->sendRequest($request, ['timeout' => 4]);

echo $response->getStatusCode();
```

The choice of factory is significant. A different compatible implementation may require different constructor names or namespace imports. The README's examples therefore show placeholders first and then give a concrete `nyholm/psr7` version.

## MultiCurl batching and HTTP/2 server push

`MultiCurl` adds two documented capabilities: batch requests and HTTP/2 server push. The server-push example sends an initial request with HTTP version `2.0`, reads the response body, extracts an asset version, and then sends requests for a stylesheet and a script. The README explains that the server may have already pushed those assets while delivering the initial response.

The example uses `push_function_callback` to control which pushed requests the client accepts. This gives an application a policy point for accepting related assets without automatically accepting every pushed request. The README does not document the callback signature, its return type, or a complete filtering example, so a custom policy would need confirmation in the project's full `doc/` documentation.

The timing figures in the README describe that particular server-push example. They do not establish a performance guarantee for other servers, proxies, or endpoints. The repository also does not document a general concurrency interface, retry schedule, backoff policy, or stream abstraction for `MultiCurl`. Batch processing and server push should therefore be verified against the specific remote service and network path an application will use.

## Buzz's deliberate limits and practical failure cases

Buzz openly rejects a feature model based on matching larger HTTP clients. The README says there are no plans to actively develop new features or change the existing API. It also says that new configuration options and client features may be rejected. This makes the library attractive when a narrow interface and a stable dependency are priorities, but it is a weak choice for a project whose transport requirements are still changing.

A basic setup can fail before any HTTP request is made if the application installs Buzz without a PSR-17 factory. The examples also show that request and response factories must be supplied in the expected positions. A different factory implementation may use different class names, so copying the example without changing its imports will not work.

The client choice also affects deployment. `FileGetContents` uses PHP's stream wrapper mechanism. `Curl` and `MultiCurl` require the cURL extension, although the README does not provide a capability table covering proxies, TLS settings, cookies, authentication, or platform support. The `examples/` directory includes `CookieListener.php` and `DigestAuthListener.php`, but the README does not explain whether these listeners work identically with every client.

The examples focus on inspecting a PSR-7 response. The README does not document exception mapping, retries, backoff, or rollback behavior. Applications that depend on those policies need another client or a separately designed layer around Buzz.

## Why Symfony HTTP Client represents a different choice

The README names Symfony HTTP Client as an alternative for developers who want a more actively maintained HTTP client. The difference is one of scope and direction. Buzz centers on a small API, three named clients, browser-like behavior, PSR messages, and backward compatibility. Its stated goal is stability after version 1.0 rather than a continually expanding client.

Symfony HTTP Client is not documented as a drop-in replacement for Buzz. The README does not provide an API mapping, compatibility table, or example showing how to migrate between them. An application therefore needs to compare transport choices, error behavior, integration support, and configuration requirements directly instead of assuming that the libraries are interchangeable.

Buzz fits a project that values a small dependency and a familiar PSR-based request model. Symfony HTTP Client is the more relevant comparison when a team expects continued development. The repository does not provide enough migration detail to estimate the conversion cost of moving an existing application from Buzz.

## Maintenance, tests, upgrades, and the MIT license

Buzz is not archived. Its last push was on 2026-05-15, and release `1.4.0` was published on the same date. The README states that there are no plans to actively develop new features or change the existing API. The release record therefore indicates a current package, while the stated development direction favors a stable surface and targeted changes.

The project follows SemVer and says it takes backward compatibility seriously. For versioned releases, a minor version should not be assumed to break the documented API, although SemVer compatibility rules differ before version 1.0.0. Upgrade reviews should still check `CHANGELOG.md` and the selected PSR-17 package, because Buzz relies on that external factory contract.

The repository documents separate unit and integration tests:

```bash
./vendor/bin/phpunit --testsuite Unit
./vendor/bin/phpunit --testsuite Integration
```

The integration suite makes real HTTP requests. The README also documents a PHP test server and an Nginx Docker setup using port `8022`. Buzz uses the MIT license. That license permits broad use, modification, distribution, and sublicensing subject to its terms. Applications should retain the applicable copyright and license notices and review their own compliance requirements.

## Conclusion

Adopt Buzz when a PHP service needs a small, stable HTTP client for conventional requests or MultiCurl batch processing. Do not choose it when you expect frequent feature expansion or a larger configuration surface. Check PHP and cURL compatibility first, then verify that your selected PSR-17 factory supports the request and response patterns your application uses.

## FAQ

### What HTTP clients does Buzz include?

Buzz includes `FileGetContents`, `Curl`, and `MultiCurl`. `MultiCurl` also supports batch requests and HTTP/2 server push.

### Why does Buzz require a PSR-17 factory?

Buzz uses a PSR-17 factory to create PSR-7 requests and responses. The README uses `nyholm/psr7` as an example and points users to the Packagist provider list for other implementations.

### Is Buzz planned to gain many new features?

The README states that there are no plans to actively develop new features or change the existing API. The repository is not archived, and release `1.4.0` was published on 2026-05-15.

## Sources

- [Issues](https://github.com/kriswallsmith/Buzz/issues)
- [kriswallsmith/Buzz on GitHub](https://github.com/kriswallsmith/Buzz)
- [License: MIT](https://github.com/kriswallsmith/Buzz/blob/master/LICENSE)
- [README](https://github.com/kriswallsmith/Buzz/blob/master/README.md)
- [Releases](https://github.com/kriswallsmith/Buzz/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/kriswallsmith-buzz