support of gzip encoding in response

[laurentj]

jResponse should provide http compression feature. For example, a property "compression". Then if client accept compression and if this property is true, jResponse return a compressed response.

[laurentj]

See :

• ​http://www.w3.org/Protocols/rfc2616/rfc2616.html

[dmp]

Exemple implementation to read Accept-encodings headers

[dmp]

Usual encodings are: array('zip', 'deflate', 'gzip', 'x-zip', 'x-deflate', 'x-gzip')

and of course 'identity'.

All these (but identity) are in fact *the same*... and means the client do accept compression...

[dmp]

I - don't forget that we need to send the proper Content-encoding if we are to perform compression

II - suggesting also to read other headers (at least Accept-charset - eg: utf8 for most people, unless client doesn't support it). IMO, this is related, as we are treating here content transformations. Same remark as above applies: need to explicitely manipulate the answer header

[dmp]

Last remarks:

Be sure to check that *we are able* to compress... extension_loaded('zlib')

To perform the compression itself, relying on something very simple is probably a good idea. eg: start bufferizing stop bufferizing compress the buffer content ---> gzdeflate($mybuff, 9); flush it out...

[marko_]

​ob_gzhandler() callback check browser capacity before sending compressed content. Don't need to check this manualy in jResponse ?

[dmp]

ob_gzhandler() is just a helper anyhow. IMHO, it's better not to rely on it. Not to mention that ​http://www.php.net/manual/en/function.ob-gzhandler.php explicitely discourage its use (and recommends using zlib.output_compression instead), having to use it as a callback for ob_start restricts your possibilities manipulating the buffer (if I understood correctly).

Anyhow, something sure is better than nothing ;)

[laurentj]

use apache/nginx/whatever features for this.