ASP.NET MVC UrlHelper.GenerateUrl exception: "Cannot use a leading .. to exit above the top directory"

Question

I am using the IIS 7 Rewrite module to rewrite an incoming url like:

http://server/year/all

to

http://server/application/controller/year/all

Everything works fine, except when, while processing the rewritten request, I use MVC's UrlHelper.GenerateUrl() method:

UrlHelper.GenerateUrl(
   "Assets",
   "Css",
   "Asset",
   new RouteValueDictionary(new { site = site.Name, assetPath = assetPath }),
   RouteTable.Routes,
   controllerContext.RequestContext,
   false);

Calling this method results in an HttpException:

System.Web.HttpException: Cannot use a leading .. to exit above the top directory.
   at System.Web.Util.UrlPath.ReduceVirtualPath(String path)
   at System.Web.Util.UrlPath.Reduce(String path)
   at System.Web.VirtualPath.Combine(VirtualPath relativePath)
   at System.Web.VirtualPathUtility.Combine(String basePath, String relativePath)
   at System.Web.Mvc.PathHelpers.GenerateClientUrlInternal(HttpContextBase httpContext, String contentPath)
   at System.Web.Mvc.PathHelpers.GenerateClientUrl(HttpContextBase httpContext, String contentPath)
   at System.Web.Mvc.UrlHelper.GenerateUrl(String routeName, String actionName, String controllerName, RouteValueDictionary routeValues, RouteCollection routeCollection, RequestContext requestContext, Boolean includeImplicitMvcValues)

Looking at the RequestContext, it seems that all of the request paths are correct (ie, have the rewritten values). I can't seem to figure out why it's trying to exit out of the top level directory... There's nowhere we are using .... in a path.

I've also made sure the RewriteModule is in above the UrlRouting module in IIS.

While I can step into the framework methods, I can't examine any of the local variables (either in VS or WinDbg) because it's been compiler optimized.

Any thoughts?

Answer 1

This is a grotesque workaround involving private implementation details, but add this:

HttpContext.Current.Request.ServerVariables.Remove("IIS_WasUrlRewritten");

This avoids the internal check done in PathHelper.GenerateClientUrlInternal to see if the request was rewritten. It's quite likely that this will break some scenarios, as hinted at by this comment in the reference sources:

// Since the rawUrl represents what the user sees in his browser, it is what we want to use as the base 
// of our absolute paths. For example, consider mysite.example.com/foo, which is internally 
// rewritten to content.example.com/mysite/foo. When we want to generate a link to ~/bar, we want to
// base it from / instead of /foo, otherwise the user ends up seeing mysite.example.com/foo/bar, 
// which is incorrect.