I have created an extension method called AddGZip which looks like the following:
public static void AddGZip(this HttpResponse response)
{
response.Filter = new GZipStream(response.Filter, CompressionMode.Compress);
response.AppendHeader("Content-Encoding", "gzip");
}
This is a very cut down version of the code:
var response = HttpContext.Current.Response;
var request = HttpContext.Current.Request;
var result = File.ReadAllText(path);
if (request.SupportsGZip)
{
response.AddGZip();
}
response.Write(result);
response.Flush();
When you view the response in a web browser with GZip support you get an error like this:
“XML Parsing Error: unclosed token
Location: http://webserver1/1234.xml
Line Number 78, Column 1:”
When i view the source it’s basically missed out the last > from the end of the XML file. So 1 or 2 bytes.
If I comment out the AddGZip Line it works fine. However I really want to support GZip as the XML can be quite large.
Does anyone have a suggestion for me? I’ve tried checking lots of blogs but no solution seems to be out there for this type of error.
Dave
There is an issue (or perhaps a really clever feature that I haven’t seen justified anywhere) with
DeflateStream(GZipStreambuilds onDeflateStreamand inherits the issue*), where flushing can lose data.Response.Flush()will flush the filter. The solution is to use a wrapper that is aware of both the zipping and the underlying sink, and only flushes the latter:It’s also worth noting that most user-agents that support gzip-encoding also support deflate-encoding. While the size improvement with deflate is negliable (literally a few bytes), some libraries on some architecture deals with deflate considerably better (this goes for both compressing and decompressing), so it’s always worth favouring deflate over gzip with HTTP compression.