[Zylius]

🔍 What was changed

The first version of rapira/symfony: a Symfony Runtime (Rapira\Symfony\Runtime) that serves a Symfony HTTP kernel from the stock public/index.php in every Rapira mode. Outside Rapira it behaves as Symfony's own runtime.

How it works

• Classic boots the kernel per request, sends the response, calls rapira_finish_request(), then runs terminate().
• Worker boots the kernel once, before the loop, and serves Rapira\handle_request() from the superglobals; terminate() runs after the client has its answer but inside the request, so uploads and max_execution_time still apply.
• Dispatcher converts each Rapira\Http\Exchange to a Symfony Request and writes the response straight into the exchange, one exchange at a time; files go out through Exchange::sendFile(), streamed bodies are forwarded as they are printed.

A failure that escapes the kernel is answered with a plain 500 (overridable through Runtime::createFailureResponse()), logged through Rapira\log(), and ends the loop so Rapira starts a fresh kernel. A kernel that cannot boot fails the worker before it takes a request, so Rapira counts it as a failed start.

Why?

Symfony apps on Rapira need a runtime that keeps the kernel resident in Worker and Dispatcher modes and maps Rapira's request and response model onto HttpFoundation without the application changing.

Review notes

• The REMOTE_ADDR placeholder in trusted_proxies resolves at boot, when $_SERVER holds no client, so it trusts no proxy in Worker and Dispatcher modes; the README says to list proxies or use PRIVATE_SUBNETS.
• Dispatcher mode needs Rapira 0.9.1+: the x86_64 Linux builds of 0.9.0 crash a worker that checks whether its exchange is cancelled.
• A worker that fails on every request is not counted as failing by the host; filed as [🐛 BUG]: A worker that fails on every request is never flagged unhealthy rapira#209.

Checklist

• How was this tested:
  • Feature tests against Rapira's fake runtime for all three modes
  • Acceptance tests against a live Rapira binary in Classic, Worker and Dispatcher modes
  • CI green on Ubuntu and Windows, PHP 8.4 and 8.5, lowest and highest dependencies

Documentation

The README covers installation, setup, mode behaviour, failure handling, the Dispatcher request and response mapping, and what Dispatcher mode does not support (superglobals, header(), EventStreamResponse).

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: ASSERTIVE
• Plan: Advanced
• Run ID: dffdbf1b-817d-420b-93eb-d82071a73976

---

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

---

_{Comment @coderabbitai help to get the list of available commands.}

[FluffyDiscord]

@Zylius "Testo"? could we use standard Phpunit?

[FluffyDiscord]

fine by me I would say, once some of the things mentioned are addressed. How it is now, its basically what the plain runtime should be doing. However I will not be able to be this as a base for symfony bundle, as its too barebone, but once again, thats the point of symfony runtime, which this fulfills

[roxblnfk]

Status update: the infrastructure and the test suite are reworked; fixes in src/ are still in progress, so this is not ready to merge yet.

Done

• CI, release-please, CODEOWNERS, .gitattributes and the dependency analyser now match the sibling bridges; tests run on Linux and Windows × PHP 8.4/8.5 plus a lowest-dependencies job.
• The tests drive the bridge only through Runtime → getRunner() → run(), with the host scripted by the rapira/testing doubles, so the test seams in src/ can be removed without touching the tests.
• An acceptance suite serves a fixture app through a live Rapira in Classic, Worker and Dispatcher modes.

Findings pinned by tests

Each one is a test with the expected behaviour, marked #[Skip('known bug: …')] until the fix lands; every one was run unskipped once to confirm it fails for the stated reason.

• Worker and Classic: a StreamedResponse that calls ob_flush() is cut after the first chunk. The Rapira SAPI starts without output_buffering and Response::send() closes every buffer under a non-CLI SAPI, so ob_flush() raises a notice that the error handler turns into an exception; the client gets the first chunk followed by the error page. Only visible on a live server (acceptance).
• Dispatcher cookies are not parsed the way PHP does: values are not URL-decoded, the last duplicate wins instead of the first, and several Cookie headers are joined with , instead of ; . A cookie set by Symfony itself does not round-trip.
• Dispatcher: a HEAD request to a BinaryFileResponse reads the whole file before discarding it.
• Dispatcher: any failure converting the request or emitting the response kills the worker without answering the client: an unreadable upload, EventStreamResponse, a terminal 1xx status, a header value the host rejects. The sibling bridges answer 4xx/5xx and keep serving.
• Dispatcher: a urlencoded form is not parsed when the Content-Type is not lowercase.
• Worker: the request served by the last handle_request() call is not terminated when the host returns false together with it. The real host returns false from a separate empty call, so this is latent; the rapira/testing double is being aligned with the host separately.

Still in progress

• Fixing the findings above in src/ and unskipping their tests.
• Building the Symfony Request directly from the exchange, dropping nyholm/psr7 and symfony/psr-http-message-bridge.
• Removing the test seams (Runtime::getMode()/getHttpDispatcher(), RequestLoop).
• rapira_finish_request() in Classic mode, uploads moved with rename() instead of copied, the behaviour for non-HttpKernel applications in resident modes, README corrections.

[roxblnfk]

Status update: the findings from the review are fixed in src/, every test pinned as a known bug now passes, and CI is green on Linux and Windows.

Done

• Worker and Classic send the response inside an own output buffer, so a StreamedResponse that calls ob_flush() is no longer cut after the first chunk. Classic mode uses an own runner everywhere: rapira_finish_request() releases the client before terminate(), and outside Rapira the stub answers false and the runner finishes the request the way Symfony's does.
• The Symfony Request is built directly from the exchange. nyholm/psr7 and symfony/psr-http-message-bridge are gone. Request parsing matches PHP and the Rapira SAPI, as rapira/http 0.1.5 does:
  • cookies are decoded and the first duplicate wins;
  • a form body is parsed by its Content-Type alone, case-insensitively, for any method, QUERY included;
  • file names are mangled as in $_FILES;
  • the query is taken from the raw request-target;
  • uploads are kept with rename() instead of a copy.
• Dispatcher responses:
  • a HEAD request no longer reads the file;
  • BinaryFileResponse goes through Exchange::sendFile();
  • streams are forwarded in 8 KiB chunks and on every ob_flush();
  • handler output echoed outside the body is sent before it;
  • a long buffered body is split.
• Dispatcher resilience: a failure before the head is written is answered with 500, logged, and the loop goes on.
• Cleanup:
  • the test seams are removed from Runtime, and the runners live in Internal\;
  • a non-HttpKernelInterface application is refused in resident modes;
  • SCRIPT_* no longer reaches Dispatcher requests, since Rapira has no document root;
  • the README describes all of this.

Found

• [🐛 BUG]: Segfault in execute_ex after Exchange::isCancelled() in dispatcher mode (Linux 0.9.0) rapira#201. On Linux, Rapira 0.9.0 crashes a Dispatcher worker (SIGSEGV in libphp.so) when Exchange::isCancelled() or isFinalized() is called inside a method. Whether it fires depends on code layout, which is why the Linux acceptance run started failing after unrelated commits. The last commit works around it:

  • serve() no longer checks isCancelled(), so an exchange cancelled while queued is handled and its response dropped on the first write;
  • emitError() tracks the head itself instead of asking isFinalized();
  • cancelledExchangeIsSkipped is skipped.

  Both sites carry a TODO, and the removal is tracked in Remove the rapira-rs/rapira#201 workaround from Dispatcher mode #2. The yii runner calls isCancelled() in the same way and is currently unaffected only by luck of layout.

• Header spoofing: Symfony's HeaderBag turns _ into -, so a field named X_Forwarded_For would pose as X-Forwarded-For, not only through HTTP_*. Field names outside [A-Za-z0-9-] are now dropped from both, as Rapira's HTTP plugin does in Worker mode.

• Global state that remains in Dispatcher mode makes Symfony serve exchanges one at a time, as the README now says:

  • output buffers around the stream and around handle();
  • the boot-time $_SERVER environment read once;
  • APP_RUNTIME_MODE written once;
  • inside Symfony itself: ini_set('default_mimetype') in prepare(), the static Request configuration, and native sessions.

  Code that needs superglobals belongs in Worker mode.

Not done

• gc_collect_cycles() after every request is still unconditional. A configurable cleanup service is proposed in Configurable memory cleanup instead of gc_collect_cycles() after every request sdk-php#14, and both call sites carry a TODO.
• The #201 workaround stays until a Rapira release fixes the crash (Remove the rapira-rs/rapira#201 workaround from Dispatcher mode #2).

[roxblnfk]

@FluffyDiscord replying here to your comment on a457931, so it does not get lost with the rebased commits:

@roxblnfk you are doing way too much for symfony runtime, these changes are meant to be in a symfony bundle, and some of them look suspiciously like the ones i have already done.

https://github.com/php-runtime/roadrunner-symfony-nyholm this is "the plain" and simple runtime. Thats what this needs to be. We can do another repo, the bundle itself, that will have full Rapira support

Agreed on the split: features belong in a bundle, this package should be the runtime. I looked at FluffyDiscord/rapira-symfony-bundle, and most of what it does — worker events, kernel reboot and debug error pages, warmers, profiling, Doctrine, Sentry, DI configuration — has no place here and should stay there.

Where I'd draw the line differently is "thin". roadrunner-symfony-nyholm is small because psr-http-message-bridge converts the request and RoadRunner's PSR-7 worker writes the response. Rapira's Dispatcher mode has no such layer, so converting the exchange and writing the response has to live somewhere, and today it lives twice: here and in the bundle. Most of the code in this PR is that conversion done right, not features:

• all three modes, with Classic and Worker fixed under the Rapira SAPI (an own buffer for ob_flush(), rapira_finish_request() before terminate(), boot-time env);
• the request parsed the way PHP fills the superglobals: cookies, forms by Content-Type, $_FILES names, raw query, spoofed header names dropped;
• the response prepared by Symfony and written to the exchange, streamed, files through sendFile();
• a failure before the head answered with 500 instead of killing the worker.

The plan:

• The runtime stays here. This repository can become a monorepo with the runtime split out into rapira/symfony-runtime, so further packages can be added here later without getting in its way.
• The bundle gets lighter. It drops its own receive loop, request factory and response writers and builds on the runtime, keeping all its features. Where it needs to hook in (error handling and kernel reboot, lifecycle events, logging), the runtime offers a few extension points that it looks up in the container after boot.
• Some things here move towards the bundle or become runtime options: capturing output echoed outside the response, the per-request gc_collect_cycles() (Configurable memory cleanup instead of gc_collect_cycles() after every request sdk-php#14), and logging failures somewhere richer than Rapira\log().

What do you think? If this works for you, I'll list the extension points the bundle would need, and we can agree on them before either side changes.

[FluffyDiscord]

@roxblnfk compare the http worker loop, I cannot use this runtime at all - and I should not.

I am overwriting how kernel restarts, I have exception handlers for each situation (out of date now for rapira 0.9.0, or 0.9.1 if that found issue is fixed l, will need to update that to bring code in line, the idea stays), I dispatch events, log things, reset services, warmup stuff, and all of this need specific steps to take/hook into in the worker loop, which plain runtime should not simply offer.

Not sure how extension points would be feasible here, not to bloat the runtime, remember, people might not want that bundle, and might want to do all of it themselves

[roxblnfk]

@FluffyDiscord good point about the worker loop, that makes sense.

What I'd still like to share is not the loop but the two pieces at its edges, which have no lifecycle at all:

• Exchange → Symfony Request: server bag, headers, cookies, query, form and multipart bodies, uploads.
• Symfony Response → exchange: head, plain and streamed bodies, files through sendFile(), HEAD and empty responses.

If rapira/symfony makes these public, your HttpWorker can use them in place of its own factory and writers, and fixes reach both packages — the issues I opened on the bundle are all in these two pieces.

Your Runtime could also extend Rapira\Symfony\Runtime and override only the Dispatcher runner, getting Classic and Worker modes with their Rapira fixes for free.

Would that work for you? If not, two independent implementations is fine too.

[Zylius]

Great review guys. Thanks for your input. One more thing I don't like about this whole PR is that to run this either the composer.json requires

{
    "extra": {
        "runtime": {
            "class": "Rapira\\Symfony\\Runtime"
        }
    }
} 

Or you need to specify it while launching the command. When switching around servers for PHP this couples the actual source files (composer.json) to the server used, or it has a cumbersome launch command. http.env entry in rapira config file would really help

[FluffyDiscord]

@FluffyDiscord good point about the worker loop, that makes sense.

What I'd still like to share is not the loop but the two pieces at its edges, which have no lifecycle at all:

• Exchange → Symfony Request: server bag, headers, cookies, query, form and multipart bodies, uploads.
• Symfony Response → exchange: head, plain and streamed bodies, files through sendFile(), HEAD and empty responses.

If rapira/symfony makes these public, your HttpWorker can use them in place of its own factory and writers, and fixes reach both packages — the issues I opened on the bundle are all in these two pieces.

Your Runtime could also extend Rapira\Symfony\Runtime and override only the Dispatcher runner, getting Classic and Worker modes with their Rapira fixes for free.

Would that work for you? If not, two independent implementations is fine too.

Let me think about this a bit. The runtime override is off the table though, too different.

[FluffyDiscord]

@roxblnfk except the error renderer, its fine as is I guess. Static calls are against how symfony works, but here whatever, the explore query is spotty I would say and other remarks are just suggestions

[roxblnfk]

Follow-ups from two independent reviews of the current state, to be addressed in this PR. Each was checked against the code; the first one also on a live Rapira.

[Zylius]

@Zylius "Testo"? could we use standard Phpunit?

rapira/testing uses testo 🤔

[roxblnfk]

Testo is OK guys

[Copilot]

🟡 Changes recommended

Trusted X-Sendfile handling can expose local paths and produce empty file responses across all runtime modes.

2 open findings

• Strip generated sendfile headers before Dispatcher response preparation · New
• Prevent unsupported X-Sendfile optimization from emptying file responses · New

What changed in this PR

Introduces the initial rapira/symfony runtime, integrating Symfony HTTP kernels with Rapira’s Classic, Worker, and Dispatcher execution modes.

Changes:

• Adds mode-specific runners and request/response translation.
• Adds comprehensive feature and live-server acceptance tests.
• Adds package documentation, CI, analysis, and release configuration.

File	Description
src/​Runtime.php	Selects the runner for each Rapira mode.
src/​Internal/​BootServer.php	Filters boot-time server variables.
src/​Internal/​ClassicRunner.php	Serves Classic-mode requests.
src/​Internal/​DispatcherRequest.php	Owns converted requests and uploads.
src/​Internal/​DispatcherRequestFactory.php	Converts exchanges into Symfony requests.
src/​Internal/​DispatcherRunner.php	Implements the Dispatcher loop.
src/​Internal/​ExchangeResponseEmitter.php	Writes Symfony responses to exchanges.
src/​Internal/​OutputBufferException.php	Represents buffer-stack corruption.
src/​Internal/​ResponseDiscardedException.php	Represents discarded responses.
src/​Internal/​SapiResponse.php	Sends SAPI responses with buffering.
src/​Internal/​UnsentResponseException.php	Wraps pre-head response failures.
src/​Internal/​WorkerRunner.php	Implements the Worker loop.
tests/​Support/​TestKernel.php	Provides a lifecycle-recording kernel.
tests/​Support/​ScriptedExchange.php	Provides a configurable exchange double.
tests/​Support/​ReadCountingStream.php	Detects unintended file reads.
tests/​Support/​PhpProcess.php	Runs bounded PHP subprocesses.
tests/​Support/​ForeignDispatcher.php	Models a non-HTTP dispatcher.
tests/​Support/​FileResponseWithoutInternalState.php	Models future file-response compatibility.
tests/​Support/​FakeRuntimeLifecycle.php	Resets fake-runtime process state.
tests/​Support/​FailurePageRuntime.php	Tests custom failure responses.
tests/​Support/​BootRecordingKernel.php	Records kernel boot ordering.
tests/​Fixtures/​file-response-compatibility.php	Exercises file-response fallback behavior.
tests/​Feature/​WorkerModeTest.php	Tests Worker lifecycle and failures.
tests/​Feature/​RuntimeTest.php	Tests runtime mode selection.
tests/​Feature/​FileResponseCompatibilityTest.php	Tests future Symfony compatibility.
tests/​Feature/​DispatcherResponseTest.php	Tests Dispatcher response emission.
tests/​Feature/​DispatcherRequestTest.php	Tests Dispatcher request conversion.
tests/​Feature/​DispatcherModeTest.php	Tests Dispatcher lifecycle and failures.
tests/​App/​rapira.toml	Configures the acceptance fixture server.
tests/​App/​public/​index.php	Defines the fixture entrypoint.
tests/​App/​Kernel.php	Implements the acceptance fixture kernel.
tests/​Acceptance/​WorkerModeTest.php	Tests live Worker mode.
tests/​Acceptance/​Support/​ServerRequests.php	Shares live HTTP assertions.
tests/​Acceptance/​DispatcherModeTest.php	Tests live Dispatcher mode.
tests/​Acceptance/​ClassicModeTest.php	Tests live Classic mode.
testo.php	Configures feature and acceptance suites.
README.md	Documents installation and runtime behavior.
composer.json	Defines package metadata and dependencies.
composer-dependency-analyser.php	Configures dependency analysis.
psalm.xml	Configures static analysis.
.php-cs-fixer.dist.php	Configures code style.
skills.json	Configures skill discovery.
LICENSE.md	Adds the BSD-3-Clause license.
CHANGELOG.md	Initializes the changelog.
.github/​workflows/​testing.yml	Runs the test matrix.
.github/​workflows/​security.yml	Audits dependency security.
.github/​workflows/​quality.yml	Runs style and static checks.
.github/​workflows/​create-release.yml	Automates release creation.
.github/​release-please/​version.json	Initializes release versions.
.github/​release-please/​config.json	Configures release notes and versions.
.github/​ISSUE_TEMPLATE.md	Adds an issue-report template.
.github/​dependabot.yml	Configures dependency updates.
.github/​CODEOWNERS	Assigns repository ownership.
.gitignore	Excludes generated artifacts.
.gitattributes	Configures archives and line endings.
.editorconfig	Defines editor formatting defaults.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Zylius]

@roxblnfk @Zylius I am still not happy for the many static calls, and some minor code related things, but there is nothing blocking the release itself AFAIK.

Has anyone tested this in their live project?

I can not test it in our production until I have a proper tag :/