IIS enabled GZip compression problems and solutions

                      When the page file is relatively large, turning on GZip compression can reduce the transmission traffic. The test is very obvious. Some people in the computer software and hardware application network use the GZip compression function of IIS. The function is also applied in the project. In the process of encountering a more difficult problem, looking for a long time has been uncertain.
In the project, the Excel2007 report file is generated on the server side. After the file is downloaded to the local, it cannot be opened normally. The file format is faulty. Because the essence of the Excel2007 file format is a compressed package, it is suspected that the file is being downloaded. Changed, but I don't know which part of the problem. Guess: 1. Because the Excel2007 file is output when the page is rendered, and the End request is directly after the output, you can infer the compression mechanism of IIS. It should be added at the beginning of the request, not at the end of the request. compressed. 2. When the file is downloaded, the download box will be popped up for downloading, and may not be decompressed by the browser. This is yet to be verified. Or there are other reasons why the compression package cannot be pressurized, because the compression package is packaged twice (the Excel2007 file was packaged once and was packaged once again when downloaded via IIS). The problem of using IIS compression (currently found): 1. The configuration is inconvenient. To change the configuration file in the system, if there is not enough permission, there is no way to configure it. 2. IIS6 will affect all sites in IIS, it is said that IIS7 does not have this problem. 3. Configured the IIS compressed machine, the configuration is lost after a few restarts (strange things). 4. Excel2007 download problem, it is estimated that there will be problems in the OOXML format. Solution: The solution is to use HttpModule for compression, use PostReleaseRequestState event in HttpModule to compress, delay the compression time to Render, the usual code will not uninstall Render:) Since PostReleaseRequestState event is after Render Someone will have doubts, it can also be subscribed in the page. In my actual test, I found that I can't change the Response.Filter in the page logic. I will report an error. This may involve some permissions in asp.net. So, still honestly implement it in HttpModule. Using System;
using System.Collections.Generic;
using System.Text;
using System.Web;
using System.IO;
using System.IO.Compression;

namespace CapabilityTest
{
public class CompressModule : IHttpModule
{
#region IHttpModule Members

public void Dispose()
{
//throw new NotImplementedException();
}

public void Init(HttpApplication context)
{
context.PostReleaseRequestState += new EventHandler(context_PostReleaseRequestState);
}

# Endregion

private const string GZIP = "gzip";
private const string DEFLATE = "deflate";

private void context_PostReleaseRequestState(object sender, EventArgs e)
{
HttpApplication app = sender as HttpApplication;
Stream filter = app.Response.Filter;

if (IsEncodingAccepted(app.Request, GZIP))
{
app.Response.Filter = new GZipStream(filter, CompressionMode.Compress);
app.Response.AppendHeader("Content-Encoding", GZIP);
}
else if (IsEncodingAccepted( app.Request, DEFLATE))
{
app.Response.Filter = new DeflateStream(filter, CompressionMode.Compress);
app.Response.AppendHeader("Content-Encoding", DEFLATE);
}
}

private static bool IsEncodingAccepted(HttpRequest request, string encoding)
{
string acceptEncoding = request.Headers["Accept-Encoding"];
if (acceptEncoding == null)
return false;

acceptEncoding = acceptEncoding.ToLower();
if (encoding == GZIP)
return acceptEncoding.Contains(GZIP)