Supporting custom compression algorithm for IIS served content

I have a bunch of internet devices which communicate with my MVC app on IIS 7.5. I'm currently using the built-in dynamic transparent compression (gzip/deflate).

I'd like to be able to support a different compress开发者_JAVA百科ion algorithm, which does a lot better than gzip (7zip) for the content I'm sending/receiving.

In other words, on the client I will add the header: accepts: gzip, deflate, 7zip (or similar), and the server will recognize this, and apply the best choice when sending the content.

What's the best way to go about hooking this all together? (I know how to implement the actual 7zip encode/decode aspect)

Thanks.

---

On the server side, you can compress your responses using an HttpModule. An HttpModule is similar to global.asax in that it exposes request and response lifecycle events like BeginRequest, ReleaseRequestState, and EndRequest. You can alter the contents of a response by handling the appropriate event and changing the output stream. Typically you alter a response by attaching an output filter. As an example, the blowery HttpCompress module(no longer updated) attaches compression filters in the ReleaseRequestState or PreSendRequestHeaders events:

http://code.google.com/p/httpcompress/source/browse/trunk/HttpCompress/HttpModule.cs

In addition to compressing the content, you'll need to set the Content-Encoding header. For a more recent(though beta) example, check out Rich Crane's Wicked Compression module. CodeProject also has an example module.

Keep in mind, a compressing HttpModule will likely not play nice if IIS is set to compress at the server level. In addition, be prepared for a few corner cases if you're using Ajax or .axd handlers. These requests may not work like you expect or may not pass through your module without explicitly wiring them in.

On the client side, you'll need to pass your custom Accept-Encoding token with each request. Avoid compressing on the server if this token isn't set. If you add clients in the future, it may not be clear why they're failing if all responses are compressed with your custom compression.

I'm not sure how your clients are making requests, but most Http Request/Response pipelines allow you tap into the response stream in a similar way to the server. Before the response is sent to your renderer, check for your custom Content-Encoding token. If it's present, run your decompression routine. If not, pass the response through unaltered.