GZIP Compression Issues

Your GZIP compression setup might not be optimal, but you’re not sure how to investigate the issue? Below are the most common causes of GZIP-related errors, along with the recommended actions to diagnose and resolve them.

Cause	Description	Recommended actions
The payload is compressed twice	In this case, the request body is already GZIP-compressed and then compressed again.	Validate the gzip structure of your payload Try to decompress it, the result should be a JSON If decompression results in binary data instead of JSON, the payload is likely double-compressed.
The payload is not compressed, only the HTTP header is set	Setting the Content-Encoding: gzip header is not sufficient. The request body itself must be GZIP-compressed.	Inspect the request body you are sending. If the body is readable JSON, it is not compressed. A properly GZIP-compressed payload should look like unreadable binary (“gibberish”).
The payload is truncated (Content-Length mismatch)	If the payload is cut off during transmission, the Content-Length header will not match the actual payload size, causing decompression to fail.	Compare the output with the Content-Length value set in the HTTP header. Both values must match exactly.
A different compression format is used	We only support GZIP compression. Other formats (such as raw zlib) are not compatible.	A valid GZIP payload should always starts with: 00000000 1f 8b 08 . If these bytes are missing, the payload is not GZIP-compressed.

If the issue persists after following the steps above, you can share an example of the raw encoded payload (i.e. the exact bid request body you are sending to us) with your Solution Engineer or at [e-mail].

We can perform a quick review to help identify potential issues; however, please note that our analysis will be limited and does not replace full debugging on your side.