Uri.IsWellFormedUriString for relative Hashbang urls compatibility
In the following tests, why does (only) the last one fail?
[Fact]
public void IsWellFormedUriString_AbsolutNonHashTagUri_ReturnsTrue()
{
Assert.True(Uri.IsWellFormedUriString("http://www.RegularSite.org/Home", UriKind.Absolute));
}
[Fact]
public void IsWellFormedUriString_RelativeNonHashTagUri_ReturnsTrue()
{
Assert.True(Uri.IsWellFormedUriString("Home", UriKind.Relative));
}
[Fact]
public void IsWellFormedUriString_AbsolutHashTagUri_ReturnsTrue()
{
Assert.True(Uri.IsWellFormedUriString("http://www.w3.org/#!Home", UriKind.Absolute));
}
[Fact]
public void IsWellFormedUriString_RelativeHashTagUri_ReturnsTrue()
{
// Fails!
Assert.True(Uri.IsWellFormedUriString("#!Home", UriKind.Relative));
}
If Uri recognizes Hashbangs in the Absolute version of IsWellFormedUriString , why not in the Relative version? What am I missing?
Note: This doesn't help.
The reason this isn't working as you'd expect is because a hashbang isn't part of the URI Scheme. The method is expecting the hierarchical part of the URI format and a hash mark (and subsequently a hashbang) is not a member of the hierarchical part from which a relative and absolute path is determined.
< > is a required part
[ ] is an optional part
<scheme name> : <hierarchical part> [ ? <query> ] [ # <fragment> ]
as an example of an absolute URI; the query, if I'm not mistaken is ignored, which includes the fragment and hash mark
http://domain.com/path/to/something/?query=1#fragment
Here is some more information for you as well. This is all from the MSDN describing the Uri.IsWellFormedUriString() method
Indicates whether the string is well-formed by attempting to construct a URI with the string and ensures that the string does not require further escaping.
Remarks:
By default, the string is considered well-formed in accordance with RFC 2396 and RFC 2732. If International Resource Identifiers (IRIs) or Internationalized Domain Name (IDN) parsing is enabled, the string is considered well-formed in accordance with RFC 3986 and RFC 3987.
The string is considered poorly formed, causing the method to return false, if any of the following conditions occur
The following are some failure examples:
http://www.contoso.com/path???/file name
The string is not correctly escaped.
c:directoryfilename
The string is an absolute Uri that represents an implicit file Uri.
file://c:/directory/filename
The string is an absolute URI that is missing a slash before the path.
http:host/path/file
The string contains unescaped backslashes even if they will be treated as forward slashes
www.contoso.com/path/file
The string represents a hierarchical absolute Uri and does not contain "://"