I recently ran into a surprising limitation in Reporting Services.  I say surprising because I honesty didn’t know it was a limitation, not because I am surprised at the limitation.  It also turns out that this limitation is unfortunately not documented in the Reporting Services documentation.

GZIP (see the Other Uses section of http://en.wikipedia.org/wiki/Gzip) is a standard mechanism for compressing streams between IIS and a client.  Turning it on at the IIS level is as simple as using adsutil.vbs (see the IIS documentation).  Most modern browsers add the Accept-Encoding: gzip, deflate header since they can properly decompress the stream from IIS.

This is where the problem comes in for Reporting Services (SSRS).  SSRS does all of its interaction with its web service component through the ReportViewer control (even from within Report Manager).  There are both WinForms and WebForms version of the control, but they are basically the same.  Unfortunately, neither of the controls knows how to decompress the HTML stream that comes back from a GZIP-compressed IIS instance.  That means you will get an error similar to:

Response is not well-formed XML. ''. hexadecimal value 0x1FR, is an invalid character. Line 1, position 1.

Bummer, huh?

At this point, there is no solution for this problem.  However, change requests have been put in to enable this feature in future releases of Reporting Services.  This would like mean that, not only would the ReportViewer controls be able to decompress the stream, but the ReportServer web service would be able to compress the stream (remember – post-SSRS 2005, SSRS has no dependency on IIS, so cannot rely on IIS’ built-in capabilities).