php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #69493 Compress by default
Submitted: 2015-04-21 08:02 UTC Modified: 2021-07-31 10:33 UTC
From: olafvdspek at gmail dot com Assigned:
Status: Open Package: *General Issues
PHP Version: Irrelevant OS: *
Private report: No CVE-ID: None
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
MUST BE VALID
Solve the problem:
8 + 23 = ?
Subscribe to this entry?

 
 [2015-04-21 08:02 UTC] olafvdspek at gmail dot com
Description:
------------
It'd be nice if output compression was enabled by default.
Perhaps based on content type such that text/* and javascript are compressed.
Obviously the default should not cause troubles with scripts that enable compression themselves.

Test script:
---------------
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World


Expected result:
----------------
Output compression

Actual result:
--------------
No output compression

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2021-07-26 13:41 UTC] cmb@php.net
-Status: Open +Status: Feedback -Assigned To: +Assigned To: cmb
 [2021-07-26 13:41 UTC] cmb@php.net
Oh, is it that hard to enable that setting in php.ini, or even
better, not to use it, but rather configure your Webserver to do
that?
 [2021-07-26 13:48 UTC] rtrtrtrtrt at dfdfdfdf dot dfd
it's not hard to let take care about compression in the webserver, but it doesn't make enough problems for some people when it's done based on request-headers so that it works without issues :-)

and hell: the webserver even can decide if brotli or gz compression satisfies the client, way too less troubles
 [2021-07-27 07:40 UTC] olafvdspek at gmail dot com
-Status: Feedback +Status: Assigned
 [2021-07-27 07:40 UTC] olafvdspek at gmail dot com
> Oh, is it that hard to enable that setting in php.ini, 

It's not that hard.. but I think it could be simpler. 

> or even
> better, not to use it, but rather configure your Webserver to do
> that?

Is that better / recommended? Is that recommendation documented? ;)
 [2021-07-27 14:24 UTC] cmb@php.net
-Status: Assigned +Status: Open -Assigned To: cmb +Assigned To:
 [2021-07-27 14:30 UTC] rtrtrtrtrt at dfdfdfdf dot dfd
> Is that better / recommended?

it was never the job of the scripting language to handle http compression

> Is that recommendation documented?

surely: https://httpd.apache.org/docs/2.4/mod/mod_deflate.html
 [2021-07-31 10:33 UTC] olafvdspek at gmail dot com
> it was never the job of the scripting language to handle http compression

Sorry, I must've been doing it wrong for the past 20 years.

At https://www.php.net/manual/en/zlib.configuration.php I don't see anything about it being deprecated / not recommended.
 [2021-07-31 11:16 UTC] fjdjrr dot fffzira at dhf dot hh
yes, you did it wrong the past 20 years, i did that too 20 years ago but it only took me a year to realize that http compression only works proper if all request headers are taken into account on both sides and that it's idiotic trying to do that in the scripting language

why is it idiotic doing that in the scripting language? 

because its the webserver which is responsible for http and so common sense says the http-compression which is a part of that belongs there 

while you discuss on the wrong end we use brotli instead of gzip for modern clients over two years now
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Fri Apr 19 22:01:28 2024 UTC