Bug? - HttpContext.RewritePath() on a static file causes the file not to be compressed in response

I think I have found a bug around HttpContext.RewritePath() that would need to be looked over by IIS development team. I could not find any page or website where to report the bug, so I will report it here. Here is how to reproduce the problem: 1 - Create a new website project in Visual Studio. 2 - In web.config, make all requests to be trapped by the managed code using the following: runAllManagedModulesForAllRequests="true" 3) In Global.asax, add void Application_BeginRequest(object sender, EventArgs e) {}. Make it call HttpContext.RewritePath(). Rewrite the path like the original. It doesn't have to be a different path. 4) Publish the website on IIS 7.5. Make sure gzip compression is active on the website for both dynamic and static content. 5) Put a large css file with valid css content in there (the file has to be large enough so IIS will want to compress it before sending it). 6) Launch requests to get the css file from the published website. The first request will work. 7) Quickly clear the browser cache and make another request to the css file until the url is considered a frequent hit. Depending on frequenthittreshold configuration on your server, at most 10 seconds must elapse between requests for IIS to consider the url as a frequent hit. 8) Once the file is considered a frequent hit, the browser will fail at decoding the response from IIS. If you look in fiddler, you will notice that the encoding is set to gzip in the response header, but the content of the response is actually not compressed. The expected result is that the response to be compressed as it should be so browsers can properly decompress the payload of the response, no matter if the file is a frequent hit or not.