Symfony, "the current responseWriter is not a flusher"

[aleho]

Looking at the log in an application with FrankenPHP I get an error output the current responseWriter is not a flusher {"error": "feature not supported"} after each request.

Diving deeper into to framework code it seems there's special handling for different environments:

https://github.com/symfony/symfony/blob/24a1a25bbdeaf32686a23f830e5adadb48bfd230/src/Symfony/Component/Runtime/Runner/Symfony/HttpKernelRunner.php#L40-L47

if (\function_exists('fastcgi_finish_request') && !$this->debug) {
    fastcgi_finish_request();
} elseif (\function_exists('litespeed_finish_request') && !$this->debug) {
    litespeed_finish_request();
} else {
    Response::closeOutputBuffers(0, true);
    flush();
}

The error message is apparently caused by the else branch, of course there's neither FastCGI nor Litespeed available.

Should there be a special handling in Symfony's runtime?
Is this else branch even correct for FrankenPHP?

[dunglas]

That's super weird because:

1. We do implement fastcgi_finish_request
2. This error should never happen (even in the else) except if you do very custom things like using homemade Caddy modules etc

Could you check that you are using the latest version?

[aleho]

frankenphp --version
FrankenPHP v1.2.5 PHP 8.3.11 Caddy v2.8.4 h1:q3pe0wpBj1OcHFZ3n/1nl4V4bxBrYoSoab7rL9BMYNk=

The error output happens here if flush() is called, commenting it out gets rid of it.
Only the else branch is executed, as confirmed with XDebug.

[aleho]

Ah, I completely missed the point in your reply, sorry 😁.

Didn't know fastcgi_finish_request was supposed to be implemented and just assumed it wasn't. The reason it isn't called is the $this->debug check.

So, is flush() supposed to work? If it's not I'll open an issue in Symfony and discuss this further over there. Unfortunately the code doesn't document why in debug mode fastcgi_finish_request isn't executed.

[dunglas]

Do you have a minimal reproducer? It looks like a bug/limitation in our code (or in Caddy). I'll take a looks after the API Platform conference.

[aleho]

After a lot of debugging (PHP extensions, container setup, libraries, etc) I finally found the culprit!

As soon as an intercept block for X-Accel-Redirect handling is present in the site the error is triggered on flush.

request_header X-Sendfile-Type x-accel-redirect
intercept {
	@accel header X-Accel-Redirect *
	handle_response @accel {
		root    * /files
		rewrite * {resp.header.X-Accel-Redirect}
		method  * GET

		header Etag                {resp.header.Etag}
		header Cache-Control       {resp.header.Cache-Control}
		header Content-Disposition {resp.header.Content-Disposition}
		header Content-Type        {resp.header.Content-Type}
		header X-Robots-Tag        {resp.header.X-Robots-Tag}

		file_server
	}
}

Should I file a bug?

[dunglas]

It's likely a limitation in Caddy yes. I'm interesting in a bug report and a reproducer.

Are you using a dev version? Because this feature isn't currently available in stable versions.

[aleho]

Caddy 2.8.4 contains your feature for intercepting responses, but apparently not your later fix caddyserver/caddy/pull/6429. Maybe that's related, because I'm using FrankenPHP 1.2.5.

I'll check if your Symfony docker project can be changed to trigger the error just by adding these lines tomorrow and report back.

[aleho]

Yes, it can be reproduced in github.com/dunglas/symfony-docker by changing the Caddyfile:

diff --git a/frankenphp/Caddyfile b/frankenphp/Caddyfile
index b8bb57d..8762ed7 100644
--- a/frankenphp/Caddyfile
+++ b/frankenphp/Caddyfile
@@ -43,5 +43,23 @@
        # Disable Topics tracking if not enabled explicitly: https://github.com/jkarlin/topics
        header ?Permissions-Policy "browsing-topics=()"
 
+       request_header X-Sendfile-Type x-accel-redirect
+       intercept {
+               @accel header X-Accel-Redirect *
+               handle_response @accel {
+                       root    * /var/files
+                       rewrite * {resp.header.X-Accel-Redirect}
+                       method  * GET
+
+                       header Etag                {resp.header.Etag}
+                       header Cache-Control       {resp.header.Cache-Control}
+                       header Content-Disposition {resp.header.Content-Disposition}
+                       header Content-Type        {resp.header.Content-Type}
+                       header X-Robots-Tag        {resp.header.X-Robots-Tag}
+
+                       file_server
+               }
+       }
+
        php_server
 }

[aleho]

This is not an issue any more with the latest FrankenPHP release built on top of Caddy 2.9.