Introduce zstd & brotli compression + output buffering #2225
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR will allow FOSSBilling to provide zstd, brotli, gzip, and deflate output compression on any webserver so long as the needed extensions are installed & opens up the ability for us to have programmatic control of it within the application.
The most interesting of these would be zstd which doesn't have official support by either NGINX or Apache. It's faster than any of the other options and overall matches brotli for compression, making it by far the superior choice for output compression.
This does have the chance to break stuff, however due to introducing output buffering. Essentially any instance where code uses
exit
will first need to useob_end_flush
to ensure the output is sent to the client.Also output compression in FOSSBilling can be disabled so it can instead be handled by the webserver if desired, although I personally am in favor of being able to control as many aspects of FOSSBilling's behavior within the app itself as it helps minimize potential changes to config files once we have more webservers we provide support for (further down the line, I presume after most of the routing has been rewritten).
I plan on leaving this as a draft till others comment on what they think, as I am not entirely sure if there is perhaps a better way to make these changes.
For example: since this would already be messing with how the app outputs data, maybe we should go one step further and port a lot of the core functionality to a micro-framework such as Flight & eliminate most of the custom routing / response handling in FOSSBilling which would benefit the app in the long-run.