Introduction/Background
From my personal experience using ASP.NET, and from searching the web, I have found that the ResolveUrl
method of the Page
control (and basically,
Control
) presents us with some serious problems.
The most common one is that you just cannot use it outside of the page or control context.
Other problems are just bugs. It will not correctly handle some of the URLs you'll give it. For example,
try Page.ResolveUrl("~/test.aspx?param=http://www.test.com")
. The result is the very same input string... It will just do nothing.
By looking into the ASP.NET code using Reflector, I found that all mechanisms that are supposed to convert the relative URLs to absolute URLs will search
first for a "://" inside the string, and will return if found. So a query string is OK, unless you pass in a parameter with ://.
Yes, I know that the query string parameter should be UrlEncode
d, but if it isn't, it is still an acceptable URL. Seriously, check your browsers!
Other suggested methods on the web involve using VirtualPathUtility.ToAbsolute
, which is pretty nice and handy, unless you pass in a query
string with the URL... Because it will just throw an exception. It will also throw an exception for an absolute URL!
So I decided to find the ultimate solution.
Using the Code
First, I searched for the perfect variable that will give me the Application Virtual Path at runtime without a page context.
I found this to be HttpRuntime.AppDomainAppVirtualPath
. It will work anywhere - even inside a timer callback! It gives the path without a trailing
slash (ASP.NET makes a special effort to remove the trailing slash...), but that is OK, we can fix it :-)
Then, I did some tests on the original ResolveUrl
code, and found where I need to replace what with the AppVirtualPath
:
- When the URL begins with a slash (either / or \), it will not touch it!
- When the URL begins with ~/, it will replace it with the
AppVirtualPath
.
- When the URL is an absolute URL, it will not touch it. (
ResolveUrl
has a bug with this, as I said before...)
- In any other case (even beginning with ~, but not slash), it will append the URL to the
AppVirtualPath
.
- Whenever it modifies the URL, it also fixes up the slashes. Removes double slashes and replaces \ with /.
So I replicated all of that, but without the bugs. And here's the code:
public static string ResolveUrl(string relativeUrl)
{
if (relativeUrl == null) throw new ArgumentNullException("relativeUrl");
if (relativeUrl.Length == 0 || relativeUrl[0] == '/' || relativeUrl[0] == '\\')
return relativeUrl;
int idxOfScheme = relativeUrl.IndexOf(@"://", StringComparison.Ordinal);
if (idxOfScheme != -1)
{
int idxOfQM = relativeUrl.IndexOf('?');
if (idxOfQM == -1 || idxOfQM > idxOfScheme) return relativeUrl;
}
StringBuilder sbUrl = new StringBuilder();
sbUrl.Append(HttpRuntime.AppDomainAppVirtualPath);
if (sbUrl.Length == 0 || sbUrl[sbUrl.Length - 1] != '/') sbUrl.Append('/');
bool foundQM = false;
bool foundSlash; if (relativeUrl.Length > 1
&& relativeUrl[0] == '~'
&& (relativeUrl[1] == '/' || relativeUrl[1] == '\\'))
{
relativeUrl = relativeUrl.Substring(2);
foundSlash = true;
}
else foundSlash = false;
foreach (char c in relativeUrl)
{
if (!foundQM)
{
if (c == '?') foundQM = true;
else
{
if (c == '/' || c == '\\')
{
if (foundSlash) continue;
else
{
sbUrl.Append('/');
foundSlash = true;
continue;
}
}
else if (foundSlash) foundSlash = false;
}
}
sbUrl.Append(c);
}
return sbUrl.ToString();
}
Points of Interest
After completing the code and testing over and over again and comparing to the original ResolveUrl
, I started to test for performance...
In most cases, my code executed faster than the original ResolveUrl
by 2.7 times! I also tested inside loops that executed the code 100000s of times on different kinds of URLs.
History
This is the first version, and hopefully the last!