Many administrators who use compression on their web servers can probably tell you how fastidious the Safari browser can be when it receives compressed data. This is the browser that is developing a reputation for the dreaded "bad server response" (NSURLerrorDomain:-1011) error message that gets thrown ostensibly by merely sending compressed data.
This, however, has more to do with how the data is sent than the data being compressed.
This message is likely to show when a compressed response is sent without either the Content-length header or the Transfer-encoding: chunked header.
Whether the Content-length header is sent is highly dependent on the application server and scripting environment. ColdFusion and Tomcat often leave out the Content-Length value when they stream the data to the server. (This can sometimes be fixed inside these scripting environments by calculating the content length in your code.)
For users of httpZip 2.0.X there are two recommendations for accommodating this browser:
Adding a browser exclusion for the Safari browser
This will eliminate compressed content from being sent to the Safari family of browsers altogether. Safari users are likely to make up a very small percentage of your user base. This option is for those who want to break out the big gun for this problem.
Through the httpZip interface, click Configuration > Browsers, then build an exclusion for the Safari browser. You can use "Safari" as the UA Search String. You should only need to add the application, image and text MIME types under the Safari browser. Be sure that "compress" is deselected for each of these MIME types.
Changing the Streaming Configuration
When the Streaming Configuration in httpZip is changed from the default "Compress streams" to "Buffer streams, then compress," httpZip will buffer the response and, in most cases, provide a Content-length value with the compressed responses, preventing this error message from occurring.