Why the IIS overwrites your vary-Header with 'Accept-Encoding'

I spent some time today searching for a bug. Turned out it was a nasty one.

If you have a single line of code, being there for a single purpose, you usually expect this code to work.

My case: Setting a HTTP header on a response to a normal HTTP request. One probably would think this is a normal task. I wanted to set a header to control caching. More specifically, the ‘vary’ header, as the result of the request is dependent upon a specific header sent with the request.

Besides the line setting the vary header, I had two other lines setting cacheability to public and setting the absolute expiration for that specific response.

As expected, the expiration was set and the cacheability was set to public. But surpinsingly, the vary header always was ‘Accept-Encoding’, ignoring the value I specifically set. I tried setting the header via the cache class on the response, directly on the response, in my controller, in the EndRequest event on the application.. everything failed. I set another header on the same places, all of them worked. As soon as I wanted to change or even remove the ‘vary’ header, I had no chance. It always was sent with the value ‘Accept-Encoding’.

So I searched in my whole code base if there has been some tampering with the header. No result too. And then the nasty search began.

To make this post a bit shorter, I discovered that this is a bug in the web server that hits you as soon as you enable dynamic content compression. In this case, IIS overwrites your vary header with ‘Accept-Encoding’.

Of course it makes sense to add that value to the header, because when a GZip’ed response is cached and returned to a client that does not accept gzip as encoding, the client would receive a compressed response it can not decode. What does not make sense though, is to overwrite pre-existing vary-headers, as they usually are being set for a reason too ;-)

That bug in IIS was reported in August 2012: http://connect.microsoft.com/VisualStudio/feedback/details/758474/iis-gzip-compression-filter-removes-pre-existing-vary-header

It was not until November 2013 until it was fixed: http://support.microsoft.com/kb/2877816/en-us (at least, in November the binaries for this hotfix were built), it seems the KB article and hotfix was officially released just a few days ago.

The good: I discovered what the issue was and was able to direct my co workers to the best solution (patching the affected systems). The bad: I spent almost half a day for researching and reproducing that issue until I found the solution. The ugly: In fact, I would never have expected such a massive bug in a product like IIS, which I honestly consider rock-stable as a platform you can easily depend on.