[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