It's a bit difficult decision, as the "relative URI" could be any path string
that contain colons as a *valid* path (especially on *nix land).
We historically did allow such string that contain "http:" etc. as to be
treated as absolute (which historically worked long time).
But this test case uncovered possible other cases.
Hopefully this does not bring issues that is pretty much anticipated. Such
issues could also happen in older code anyways.
return new Uri (relativeUri, UriKind.RelativeOrAbsolute);
#else
// Don't ignore such case that relativeUri is in fact absolute uri (e.g. ResolveUri (null, "http://foo.com")).
- if (relativeUri.StartsWith ("http:") ||
- relativeUri.StartsWith ("https:") ||
- relativeUri.StartsWith ("ftp:") ||
- relativeUri.StartsWith ("file:"))
+ int idx = relativeUri.IndexOf (':');
+ if (idx > 0 && Uri.CheckSchemeName (relativeUri.Substring (0, idx)))
return new Uri (relativeUri);
else
return new Uri (Path.GetFullPath (relativeUri));
{\r
resolver.GetEntity (new Uri ("http://www.go-mono.com/"), null, typeof (File));\r
}\r
+\r
+ [Test] // bug #998\r
+ public void NullAbsoluteUriWithCustomSchemedRelativeUri ()\r
+ {\r
+ XmlResolver res = new XmlUrlResolver ();\r
+ var uri = res.ResolveUri (null, "view:Standard.xslt");\r
+ Assert.AreEqual ("view", uri.Scheme, "#1");\r
+ Assert.AreEqual ("Standard.xslt", uri.AbsolutePath, "#2");\r
+ Assert.AreEqual ("view:Standard.xslt", uri.AbsoluteUri, "#2");\r
+ }\r
}\r
}\r