Wondering if you'd considered how compression has been implemented in the LessCssHttpHandler. Using acceptEncoding.Contains("GZIP") misses explicit exclusions of GZIP, but also doesn't account for the preferred encoding as specified in the header.
I wrote a blog post a few years ago detailing the behaviour (which seems to be commonly misused);
I was going to fork, but thought I should get your opinion first.
It concerns: 'src/dotless.AspNet/LessCssHttpHandler.cs'
var acceptEncoding = (context.Request.Headers["Accept-Encoding"] ?? "").ToUpperInvariant();
context.Response.Filter = new GZipStream(context.Response.Filter, CompressionMode.Compress);
else if (acceptEncoding.Contains("DEFLATE"))
context.Response.Filter = new DeflateStream(context.Response.Filter,
Additionally, perhaps HttpCompression should also be configurable (on/off) - in case a user wants to handle compression through IIS or some middle tier.
Add an option for whether to handle css compression so that people ca…
…n do it in IIS instead as required. Fixes #169
many thanks, I enjoyed reading your blog article. It was simple to do, so I've used your code verbatim, the only change was that I noticed that although you compare case insensitive in order to get the preferred list you get back the preferred encoding name in the original casing and use it in the switch.. I've no idea if the casing ever changes but I put it to lower before switching on it.
Glad it was of some help - I was planning on forking, but you beat me to the implementation - nice work :)
And good spotting on the casing - will update my blog too.