[Mono-bugs] [Bug 77539][Nor] Changed - [PATCH] Relative client paths

bugzilla-daemon at bugzilla.ximian.com bugzilla-daemon at bugzilla.ximian.com
Mon Feb 13 17:11:57 EST 2006


Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by robertj at gmx.net.

http://bugzilla.ximian.com/show_bug.cgi?id=77539

--- shadow/77539	2006-02-13 16:35:20.000000000 -0500
+++ shadow/77539.tmp.3817	2006-02-13 17:11:57.000000000 -0500
@@ -112,6 +112,31 @@
 if (relativeUrl [0] == '#' || UrlUtils.IsRelativeUrl (relativeUrl))
 
 into:
 if (relativeUrl [0] != '~' && (relativeUrl [0] == '#' ||
 UrlUtils.IsRelativeUrl (relativeUrl)))
 
+
+------- Additional Comments From robertj at gmx.net  2006-02-13 17:11 -------
+It breaks other stuff where MS.NET uses to return absolute paths:
+
+In context of /app/dir/foo.aspx:
+
+    ResolveUrl("subdir/bar.aspx")
+
+returns "/app/dir/subdir/bar.aspx" on MS.NET
+
+I already tried these kind of patches.
+
+I don't unterstand under which circumstances MS.NET
+returns absolute or relative paths. While the docs
+state that the Url will be "just good" for the
+client, it's always absolute, like Mono's ResolveUrl.
+That's why they probably came up with ResolveClientUrl
+in .NET 2.0, which always returns relative Urls, if possible.
+
+HyperLink.NavigateUrl, Image.ImageUrl and all other WebControls
+that have a Url-like property doesn't use ResolveUrl. They use
+an internal method ResolveClientUrl. That's why I came up with
+the new method, because I felt that ResolveUrl cannot be
+changed to return relative paths here and absolute there.
+


More information about the mono-bugs mailing list