Moving towards gzip

If you are following the development closely you might have noticed that gzip popped up in a few places.

One of the reasons we are moving more towards gzip is that Tornado offers easy support for gzip-compressed data transfer both to and from the server. This makes the move to Tornado faster for us because we do not have to implement deflate compression features for Tornado right away.

The opsiconfd from opsi 4 does also support gzip and with the latest versions it preferrably returns gzip even if a client would accept other headers aswell.

For an easier transfer towards gzip the JSONRPCBackend now is able to use gzip aswell. The parameter deflate and the method setDeflate are now both obsolete. Instead you should make use of the compression parameter or setCompression method. Why not have a look at the documentation?

If you are using the JSONRPCBackend please remember that you can switch to the new methods once you have updated to python-opsi or newer!

As the (de)compression is based around HTTP headers it is simple to make your application work as desired by sending the appropriate headers. To get a gzip-compressed response from the server make sure to set your Accept-Encoding HTTP header to gzip. A response that is compressed will have the Content-Encoding header set to gzip.