Mapping Handler to Static Extension

What are some unintended consequences associated with mapping an ASP.NET HTTP Handler to a static extension like *.css?

<add verb="*" path="handler.css" type="Web.HttpHandler.ThemeCssHandler" />

By default, *.css is registered as static content in applicationHost (under IIS7):

<staticContent lockAttributes="isDocFooterFileName">
    <mimeMap fileExtension=".css" mimeType="text/css" />

Aren't static requests normally handled more efficiently by IIS alone?

The key motivation is really to have dynamic CSS served under its known extension as opposed to something like *.axd (for simplicity and compatibility with OOTB cache poli开发者_Go百科cies); but we'd like to make sure this doesn't degrade the service of non-dynamic CSS requests.

The usual way CSS files are processed is with the static file handler, so substituting your own handler has the potential of performing as well as it does. The details depend on the handler.

You can actually use the *.aspx handler for this purpose, if you want (though it takes a bit more configuration). However, one side-effect is that all dynamic content is marked with Cache-Control: private by default, which will prevent caching by proxies.

Output caching is also enabled by default for static files. If you make them dynamic, then your handler will have to enable it explicitly.