Skip to Content

AJAX, JSON and GZIP responses from SAP Portal

AJAX-enabled web applications usually load data from an HTTP Server. In the SAP world, this HTTP server can be ICM, pure AS Java or the SAP Portal. The data format normally used is JSON. Looking at the AS Java case – and thus on the SAP Portal too – you want to have a configuration that supports effectively AJAX responses from the server.

Every HTTP servers offers the possibility to zip the traffic send to the browser. And so does the HTTP Provider Service of NetWeaver AS Java too. Per default, the content will be zipped when 2 rules apply:

  1. Minimum content length matched and the MIME type is not ruled out or
  2. Minimum content length matched and the service is configured to compress the MIME type

The configuration is done using Visual Administrator and only involves changing the properties of the HTTP Provider Service. The AS Java HTTP Server is configured by default to never compress content that is already compressed or where an additional compression won’t result in significant smaller packages. The configurations were the “do never compress” types are defined is:


The list may vary from release to release, so check for yourself what your AS Java won`t compress. Example:


Packages that are not part of this list can be compressed by the HTTP server. To not create an unnecessary workload on the server, SAP configured an additional parameter that defines the minimum length a package has to have to be compressed:


This implies that a package with the size of 8192 will be compressed and be smaller than a package of the size 8191. Now, what will get compressed? Content that is not part of the NeverCompress list and exceeds 8191 bytes. Example:

Take a JSON package with the size of 10KB.


out = servletResponse.getWriter();

String data = “Lorem Ipsum […]”;


The test string data can be generated from the site The site offers the possibility to generate Lorem Ipsum texts by target size. This will create a String with the size of 10 KB. When this string is zipped, it’scompressed size is 3.34 KB. Javascript to test (can be run in the console window of Firebug):

function logon() {
  var url = “http://server:port/irj/servlet/prt/portal/prtroot/.AJAXData“;
  var xhr = new window.XMLHttpRequest;“GET”, url, true);

Running the example in Firebug gives:


The size of the package is larger than 8KB and the content-type is not part of the exclude list, so the response is compressed. To demonstrate that the rule applied here is the content length, take a version of the Lorem Ipsum text that is 4KB and is loaded from the portal by the above Javascript (AJAX).


The response is not compressed. The problem here is that a JSON response is not always larger than 8KB. It takes a lot of information to be transmitted to exceed the limit and for the AS Java HTTP server to compress the package. The HTTP Provider Service has an option called “AlwaysCompressed” that takes as an argument a list of MIME types that should be compressed. Unfortunately, the name of the option is misleading as the types defined there are not always compressed. The important parameter is still “MinimumGZIPLength”. The AlwaysCompressed parameter is only important when the parameter “CompressedOthers” is set to false.

Before changing the MinimumZIPLength parameter, an analysis of the transferred packages is necessary. With the knowledge gained there you can decide if setting a lower value for MinimumGZIPLength solves the problem or if the CompressedOthers parameter should be set to false. If there is a large number of packages of the size of 5KB, and compressing them isn`t really worth the effort – Intranet access only, compressed size is only 2% smaller – setting the MinimumGZIPLength parameter to 3KB will unnecessarily increase the workload on the server. In that case, the CompressedOthers parameter may be set to false and the MIME types of the to-be compressed files should be inserted explicitly in the AlwaysCompressed parameter.

Changing the MinimumGZIPLength parameter to 3 KB:


The parameter available that specifies whether a response should be compressed or not.


Inserting the MIME type for JSON will compress every time the JSON response the HTTP server sends.


To apply the changes, a restart of the server is necessary:


Using the example from above, the 3KB response will now look like:


When the AJAX call is now executed, the response will be compressed: from 3.4KB down to 1.4 KB.

Is it a good idea to change the parameter CompressOthers?

Let’s take as an example a file that by nature is already compress: MP3. Uploading a MP3 file to the Portal (KM): When the file gets accessed, the HTTP server will compress it:


Looking at the default configuration of the HTTP server the well known zip MIME types are listed, but not multimedia files. Sure, the compressed file will be of less size, but saving 1% of traffic while adding load on the server is worth the effort? You should at least take a look into the NeverCompressed parameter.

Be the first to leave a comment
You must be Logged on to comment or reply to a post.