There are loads of ways to find the path — either the URL or the physical path — to a page, user control or other file in an ASP.NET application. Unfortunately, however, the documentation doesn’t do a brilliant job of explaining them to you. There are also several different scenarios, depending on whether you are using conventional web forms, or URL rewriting, or Server.Transfer, or ASP.NET MVC. So I thought I’d better write down an overview of some of them for reference.

Scenario 1: direct request for a web form.

Just suppose for a minute that you have been contracted to rewrite Wikipedia in ASP.NET. So, for instance, you may end up with the page “What Wikipedia is Not” (aka “WP:NOT” or “Wikipedia’s attempt to get into the Guinness Book of Records for the most lies per kilobyte on a web page”) at http://en.wikipedia.org/wiki.aspx/WP:NOT.

In this case, you have several different properties of HttpContext.Current.Request containing different representations of it.

Request.RawUrl = "/wiki.aspx/WP:NOT" represents the path and query string parts of the URL. In this case, of course, there is no query string, but if there were, you might see it set to something like "/wiki.aspx/WP:NOT?mode=edit".

Request.Path = "/wiki.aspx/WP:NOT" represents the path part of the URL.

Request.FilePath = "/wiki.aspx" represents the part of the path to the file (in this case wiki.aspx) that is handling the request.

Request.PathInfo = "/WP:NOT" is a diff of Request.Path and Request.FilePath, giving the extraneous bit of the path that does not refer to a file in the file system.

Request.PhysicalPath = "c:\inetpub\wwwroot\wiki.aspx" is the physical path to the file that is servicing the request.

Case 2: Server.Transfer() and Server.Execute()

Sometimes, you may want to transfer control from one file to another. Let us suppose, for instance, that you decide to use several Web forms: one for articles, one for special pages, and one for article history. You do a few simple checks in wiki.aspx and decide to transfer control to another file, say, article.aspx, using Server.Transfer(). Then, another property of Request comes into play.

Request.CurrentExecutionFilePath = "/article.aspx" represents the path to the file that is currently handling the current part of the request.

Request.AppRelativeCurrentExecutionFilePath = "~/article.aspx" is the same as Request.CurrentExecutionFilePath, but relative to the root of the web application, as defined in IIS. If your application were rooted at, say, "/wiki" then Request.CurrentExecutionFilePath would be "/wiki/article.aspx".

Everything else remains unchanged.

Note that Request.CurrentExecutionFilePath is always in use: if there has been no call to Server.Transfer it will be the same as Request.FilePath.

Case 3: URL rewriting

So you have this lovely new ASP.NET version of Wikipedia up and running, it works much more smoothly, has much less downtime, and runs on only a dozen or so servers rather than a hundred. Then, you start getting hate mail from irate Wikipedians, many of whom are open source zealots who are definitely not NPOV on Microsoft Windows. Jimbo and the Arbitration Committee get involved and demand you rewrite those URLs to cover up the fact that the Wikimedia Foundation has gone over to the Dark Side.

Request.RawUrl = "/wiki/WP:NOT" represents the original path and query string parts of the URL. In actual fact, Request.RawUrlalways represents exactly what you typed into your browser.

Request.Path = "/wiki.aspx" represents the path part of the URL.

Request.FilePath = "/wiki.aspx" represents the part of the path to the file (in this case wiki.aspx) that is handling the request.

Request.PathInfo is blank. When you use URL rewriting you have to point to a real file: you can’t use a PathInfo — that’s why you need to use a query string instead.

Request.CurrentExecutionFilePath = "/wiki.aspx" until you call Server.Transfer, when it changes.

Request.QueryString = "ns=Wikipedia&pg=What_Wikipedia_is_Not" is of course changed after the URL rewrite.

Request.PhysicalPath = "c:\inetpub\wwwroot\wiki.aspx" is, again, the physical path to the file that is servicing the request.

Case 4: ASP.NET MVC

So how on earth, you may be asking, does all this work with ASP.NET MVC? After all, it doesn’t use Web forms in the same way — URLs map to controllers, which then decide which views to render themselves.

Request.Path, Request.FilePath, and Request.CurrentExecutionFilePath, all contain the “path” part of the URL without the query string. They will all be set to "/wiki/WP:NOT"

Request.PathInfo is blank. ASP.NET MVC handles path info through the routing engine and passes it in the parameters for your controller.

Request.PhysicalPath = "c:\inetpub\wwwroot\wiki\WP:NOT" is NOT the physical path to the file that is servicing the request. Controllers may decide to render one of any number of views or other results, and they need not even be Web forms — they could be raw text content (from a ContentResult), or a redirect (from a RedirectResult or a RedirectToRouteResult) or a JSON string (from a JsonResult) and they aren’t associated with a physical file on the filesystem at all.

Case 5: ASP.NET MVC with URL rewriting and/or Server.Transfer

I shall leave this one as an exercise for the reader. No doubt there is someone, somewhere, who is doing this, for reasons that completely befuddle me. After all, I’d have thought that the whole MVC pattern renders URL rewriting and Server.Transfer pretty much redundant.

Case 6: Requests for a directory’s home page

This is much the same as the above, except that ASP.NET inserts the name of the home page — typically default.aspx — into Request.RawUrl, and, by extension, everything else. Obviously, this does not apply to ASP.NET MVC.