[펌] HTTP Compression A Quick and Dirty Solution

>> 출처: http://www.codeproject.com/aspnet/HttpCompressionQnD.asp

IIS 6.0의 HTTP Compression을 이용하지 않고 .NET에서 자체적으로 HTTP Compression을 적용하도록 하는 방법으로, HTTP Compression을 지원하지 않는 브라우저 등을 판별하여 선택적으로 적용할 수 있게 해주는 유용한 글을 퍼왔음.

Introduction

 

HTTP Compression is a great thing: it can save up to 70% of the bandwidth. HTTP Compression could be a problem: if you don't have access to IIS, you cannot enable it, for instance. These considerations made me look for a different solution, to be used in particular conditions. In this article, I describe how to implement HTTP Compression on single ASP.NET pages, maintaining compatibility with most browsers, and without touching IIS.

 

HTTP Compression Made Easy

 

All the modern browsers support HTTP Compression. I tested this solution with Microsoft Internet Explorer 6 SP1, Mozilla Firefox 1.5.0.4, and Konqueror. The latter has a few (known) problems with GZip streams: the pages are displayed correctly, but a warning message is shown.

When the browser supports HTTP Compression, it sends to the server a specific request header:

 

Accept-encoding: gzip, deflate

 

When the server receives that header, it can enable HTTP compression. The server, if it decides to use HTTP Compression, must notify the browser using the response header:

 

Content-encoding: gzip

-- or --

Content-encoding: deflate

 

The server then appends the content compressed using the GZip or Deflate algorithm. Note: there are a few other compression algorithms, but they are not supported by all browsers. For further information, take a look at Wikipedia.

 

The Code

 

The code is unbelievably simple, and uses the property Filter of the Page object. This property allows you to perform operations on the output stream of the page, for example, replacing every occurrence of :) with the appropriate HTML tag, just to display the smiley (I use this method in my blog). We only have to "replace" the whole output with its compressed bit stream. All we need is to put this simple code snippet in the Page_Load method:

 

protected void Page_Load(object sender, EventArgs e) {
  if(Request.Headers["Accept-encoding"] != null &&
     Request.Headers["Accept-encoding"].Contains("gzip")) {
       Response.Filter = new GZipStream(Response.Filter, 
                         CompressionMode.Compress, true);
       Response.AppendHeader("Content-encoding", "gzip");
  }
  else if(Request.Headers["Accept-encoding"] != null &&
          Request.Headers["Accept-encoding"].Contains("deflate")) {
      Response.Filter = new DeflateStream(Response.Filter, 
                        CompressionMode.Compress, true);
      Response.AppendHeader("Content-encoding", "deflate");
  }
}

 

The code "plugs" a GZipStream or a DeflateStream into the Filter object (it's an instance of System.IO.Stream), trying to detect which algorithm the browser supports. Note: the two classes (GZipStream and DeflateStream) use the same compression algorithm.

Refinements

 

Since it seems that Konqueror has problems with GZip/Deflate, we should disable HTTP Compression for that browser. We can do that by checking the User Agent. The code then becomes:

 

protected void Page_Load(object sender, EventArgs e) {
  if(!Request.UserAgent.ToLower().Contains("konqueror")) {
    if(Request.Headers["Accept-encoding"] != null &&
       Request.Headers["Accept-encoding"].Contains("gzip")) {
          Response.Filter = new GZipStream(Response.Filter, 
                            CompressionMode.Compress, true);
          Response.AppendHeader("Content-encoding", "gzip");
    }
    else if(Request.Headers["Accept-encoding"] != null &&
            Request.Headers["Accept-encoding"].Contains("deflate")) {
          Response.Filter = new DeflateStream(Response.Filter, 
                            CompressionMode.Compress, true);
          Response.AppendHeader("Content-encoding", "deflate");
    }
  }
}

 
Conclusions and Disclaimer

 

As the article's title states, this is a quick and dirty solution, with all its problems, bugs, and worst-practices. It should be considered a mere proof-of-concept, although it actually works. In the coming weeks, I'll investigate deeply into this topic because I believe it may actually become a nice way to implement HTTP Compression on a per-page basis.