Today I was working on a blog plug-in for an existing application. The application is an ASP.NET MVC application so the application uses MVC’s routing to handle file access for the most part. One of the requirements for the blogging component is that it has to integrate with Windows Live Writer handling posting and updates to posts. One of the requirements for Live Writer to supported extended post properties when uploading new posts is a Live Writer Manifest file.
Serving the wlwmanifest.xml File from a Subfolder
The issue is that the manifest file has to live at a very specific location in the blog's root folder using an explicit filename.
If your site is running from a Web root, that's not a problem – it's easy to link to static files in the Web root, because MVC is not managing the root folder for routes (other than the default empty ("") route). So if you reference wlwmanifest.xml in the root of an MVC application by default that just works as IIS can serve the file directly as a static file.
Problems arise however if you need to serve a 'virtual file' from a path that MVC is managing with a route. In my case the blog is running in a subfolder that is a MVC managed routed path – /blog. Live writer now expects the wlwmanifest.xml file to exist in the /blog folder, which amounts to a URL like the following:
Sounds simple enough, but it turns out mapping this very specific and explicit file path in an MVC application can be tricky.
MVC works with Extensionless URLs only (by default)
ASP.NET MVC automatically handles routing to extensionless urls via the IIS ExtensionlessRouteHandler which is defined in applicationhost.config:
<system.webServer> <handlers> <add name="ExtensionlessUrlHandler-Integrated-4.0" path="*." verb="GET,HEAD,POST,DEBUG" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" responseBufferLimit="0" /> </handlers> </system.webServer>
Note the path="*." which effectively routes any extensionless URLs to the TransferRequestHandler which is MVC's entrypoint.
This handler routes any extensionless URLs to the MVC Routing engine which then picks up and uses the routing framework to route requests to your controller methods – either via default routes of controller/action or via custom routes defined with [Route()] attributes. This works great for MVC style extensionless routes that are typically used in MVC applications.
Static File Locations in Routed directories
However, things get tricky when you need to access static files in a directory that MVC routes to. For the Live Write scenario particularly I need to route to:
The problem is:
- There’s no physical blog folder (wlwmanifest.xml resides in the root folder)
- /blog/ is routed to by MVC
- /blog/ is a valid and desirable MVC route
- wlwmanifest.xml can’t be physically placed in this location
And that makes it rather difficult to handle the specific URL Live Writer expects in order to fine the manifest file.
There are a couple of workarounds.
Skip Routing use UrlRewrite
After futzing around with a bunch of different solutions inside of MVC and the routing setup, I instead decided to use the IIS UrlRewrite module to handle this. In retrospect this is the most efficient solution since IIS handles this routing at a very low level.
To make this work make sure you have the IIS Rewrite Module installed – it’s an optional component and has to be installed via the IIS Platform installer.
Then add the following to your web.config file:
<system.webServer> <rewrite> <rules> <rule name="Live Writer Manifest"> <match url="wlwmanifest.xml"/> <action type="Rewrite" url="blog/manifest"/> </rule> </rules> </rewrite> </system.webServer>
This effectively routes any request to wlwmanifest.xml on any path to a custom MVC Controller Method I have set up for this. Here’s what the controller method looks like:
[AllowAnonymous] [Route("blog/manifest")] public ActionResult LiveWriterManifest() { return File(Server.MapPath("~/wlwmanifest.xml"), "text/xml"); }
This is an efficient and clean solution that is fixed essentially through configuration settings. You simply redirect the physical file URL into an extensionless URL that ASP.NET can route as usual and that code then simply returns the file as part of the Response. The only downside to this solution is that it explicitly relies on IIS and on an optionally installed component.
Custom Path to TransferRequestHandler
Another, perhaps slightly safer solution is to map your file(s) to the TransferRequestHandler Http handler, that is used to route requests into MVC. I already showed you that the default path for this handler is path="*." but you can add another handler instance into your web.config for the specific wildcard path your want to handle. Perhaps you want to handle all .xml files (path="*.xml") or in my case only a single file (path="wlwmanifest.xml").
Here's what the configuration looks like to make the single wlwmanifest.xml file work:
<system.webServer> <handlers> <add name="Windows Live Writer Xml File Handler" path="wlwmanifest.xml" verb="GET" type="System.Web.Handlers.TransferRequestHandler" preCondition="integratedMode,runtimeVersionv4.0" responseBufferLimit="0" /> </handlers> </system.webServer>
Once you do this, you can now route to this file by using an Attribute Route:
[Route("blog/wlwmanifest.xml")] public ActionResult LiveWriterManifest() { return File(Server.MapPath("~/wlwmanifest.xml"), "text/xml"); }
or by configuring an explicit route in your route config.
Enable runAllManagedModulesForAllRequests
If you really want to route files with extensions using only MVC you can do that by forcing IIS to pass non-Extensionless Urls into your MVC application. You can do this by enabling the runAllManagedModulesForAllRequests option on the section in the IIS configuration for your site/virtual:
<system.webServer> <modules runAllManagedModulesForAllRequests="true" /> </system.webServer>
While this works to hit the custom route handler, it’s not really something I typically want to enable as it routes every type of document – including static files like images, css, javascript – through the MVC pipeline which adds overhead. Unless you’re already doing this to perform special manipulation of static files, I wouldn’t recommend enabling this option.
Other Attempts
As is often the case, all this looks straight forward in a blog post like this but it took a while to actually track down what was happening and realizing that IIS was short-circuiting the request processing for the .xml file.
Before I realized this though I went down the path of creating a custom Route handler in an attempt to capture the XML file:
public class CustomRoutesHandler : RouteBase { public override RouteData GetRouteData(HttpContextBase httpContext) { var url = httpContext.Request.Url.ToString(); if (url.ToLower().Contains("wlwmanifest.xml")) { httpContext.Response.ContentType = "text/xml"; httpContext.Response.TransmitFile("~/wlwmanifest.xml"); httpContext.Response.End(); } return null; } public override VirtualPathData GetVirtualPath(RequestContext requestContext, RouteValueDictionary values) { return null; } }
To hook up a custom route handler:
public static void RegisterRoutes(RouteCollection routes) { routes.IgnoreRoute("{resource}.axd/{*pathInfo}"); routes.IgnoreRoute("{resource}.ashx/{*pathInfo}"); routes.Add(new CustomRoutesHandler()); routes.MapMvcAttributeRoutes(); routes.MapRoute( name: "Default", url: "{controller}/{action}/{id}", defaults: new { controller = "Home", action = "Index", id = UrlParameter.Optional } ); }
The route handler explicitly checks each request coming in and then overrides the behavior to load the static file.
But alas, this also doesn’t work by default because just like a route that tries to look at an XML file, the file is never actually passed to the MVC app because IIS handles it.
Nevertheless it's good to know t that MVC has the ability to allow you to look at every request it does handle and customize the route or processing along the way which allows for short circuiting of requests which can be useful for special use cases. Irrelevant to my initial problem, but useful and worthwhile to mention in this context :-)
Summary
File based URL access is one of those cases that should be super simple and obvious, but is not. It requires a relatively simple but non-obvious workaround to ensure that you can handle a Url with an extension by either using UrlRewrite or adding an explicit file mapping to the TransferRequestHandler.
Incidentally in ASP.NET 5 (MVC 6) – assumes you’re handling all requests anyway as you are expected to build up the entire request pipeline – including static file handling from scratch. So I suspect in future versions of MVC this sort of thing will be more natural, as long as the host Web server stays out of the way…