Using custom handlers with output buffering

[BelleNottelling]

Hi all!

Recently I began work on CompressionBuffer to work with output buffering in PHP to allow any PHP application to have brotli and zstd output compression (and gzip too) on any webserver with it automatically selecting the best one based on the client's headers and what extensions are installed in PHP.

Using this you can get modern, insanely fast compression on even the PHP development server or for example zstd compression before either httpd or NGINX get official support for it.

I thought it would be interesting to be able to use this with apps built using Flight, but looking at the code that doesn't really seem like the case.

It could work with v2 output buffering by passing the handler here, but that's deprecated and to be removed in v4.

So to me this leaves three options:

1. Build a custom engine that incorporates it.
2. Making a relatively minor change to the flight engine to allow the user to specify a final callback before the body is sent to the client.
3. Having Flight::start(); wrapped in it's own output buffer that uses CompressionBuffer.

Not sure what the ideal way to go about that would be, so I'm curious on your general thoughts.

Thanks!

[n0nag0n]

Hey there!

So 1. Yeah that would be an option if you wanted to handle that and probably use 3. to override the default behavior.

2. Would be easy to implement. I would probably do something like Flight::set('flight.output_buffer_callback', 'ob_gzhandler'); and then in Engine.php and Response.php you would just need to call that variable (probably inject it into the response). That's a relatively small change. What do you think?

[BelleNottelling]

Would be easy to implement. I would probably do something like Flight::set('flight.output_buffer_callback', 'ob_gzhandler'); and then in Engine.php and Response.php you would just need to call that variable (probably inject it into the response). That's a relatively small change. What do you think?

The issue is I don't believe this would work work with either ob_gzhandler or CompressionBuffer, at least not with how the v3 output buffering works. Unless I am misunderstanding the code, each route's output is captured into it's own buffer and then written into the response body.

At the end, that response body is sent to the client via echo.

So that workflow could result in multiple compressed messages sent to the client which doesn't appear to be properly handled in all cases.

Take this test code:

<?php

use HostByBelle\CompressionBuffer;
require 'vendor/autoload.php';
CompressionBuffer::setUp();
$result = CompressionBuffer::handler('If you can read this, it works!');
$result.= CompressionBuffer::handler('I do not think this will work');
echo $result;

Now somewhat to my surprise, Chrome with zstd actually does display both parts of the body:

However for both Chrome and Firefox you'll only get whatever was compressed first when using gzip or deflate:

I haven't tested brotli compression as I'm on my Windows PC and don't have the extension for it installed, but either way I think it's pretty fair to say for the specific use-case of compressing the output it needs to be done on the completed output before being sent rather than each individual step.

For a lot of use cases, being able to directly register a handler with ob_start probably is sufficient though, but in this case where it's encoding the output I think an option to register a final callback that's used before sending the complete output would do nicely.

I can very easily set the default phase value for CompressionBuffer to PHP_OUTPUT_HANDLER_FINAL which will cause it to just send the appropriate header and return the compressed data, making it easily usable as a standalone function without directly registering it with ob_start & only require that the data to compress is passed to the first parameter.

The option for a final callback may also prove useful in cases like #549

[BelleNottelling]

Whoops.. apparently doing "quote reply" on a comment with GH discussions doesn't actually start it off as a comment under the original

[BelleNottelling]

Update: I've now tested brotli on my laptop and both Firefox and Chrome will only display whatever was the first part of the output.
So zstd appears to be the only case where multiple outputs being compressed and then appended to the final output works.

[n0nag0n]

Ahh I see......interesting......feels like we should wait until the final response is build and handled in response->send() and compress it there.

[BelleNottelling]

Yes, I think something along those lines would be great!

[n0nag0n]

I'd like to say this took me a long time, but it was about 10 minutes of work haha #571