Uri.IsWellFormedUriString for relative Hashbang urls compatibility

Question

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.

Laverty

Answer 1

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:\directory\filename
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 "://"

Archer

Thanks for the detailed answer, but according to it - the third test should have failed, and it doesn't. This doesn't answer my question. – Laverty

@Laverty No, third test would pass because you have http://www.w3.org/ as an absolute Uri which is enough for it to pass because it detects # as the start of a fragment and !Home as the fragment text, therefore it passes. – Archer