Bug 22954 - Domain-rooted relative URI is reported as absolute
Summary: Domain-rooted relative URI is reported as absolute
Alias: None
Product: Class Libraries
Classification: Mono
Component: System ()
Version: 3.8.0
Hardware: All Linux
: --- normal
Target Milestone: Untriaged
Assignee: marcos.henrich
Depends on:
Reported: 2014-09-12 15:49 UTC by David Straw
Modified: 2015-09-04 02:33 UTC (History)
4 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description David Straw 2014-09-12 15:49:00 UTC
Mono treats domain-rooted relative URIs (ex: "/abc") differently than .NET. In .NET these URIs are considered relative, but in Mono they are considered absolute. This causes problems in any code that relies on this distinction such as System.Net.Http.HttpClient.

Test case:

var uri = new Uri("/abc", UriKind.RelativeOrAbsolute);
Assert.False(uri.IsAbsoluteUri); // Fails in Mono
Comment 1 David Straw 2014-09-12 15:50:19 UTC
I tested this in Mono 3.4, 3.6 and 3.8. All of these versions produced the same result.
Comment 2 David Straw 2014-09-12 17:18:10 UTC
Looking at the implementation of UriParseComponents, it's pretty clear that this behavior is by design to support UNIX-style file paths. However it seems to me that supporting web URIs properly should probably take precedence. Would it be reasonable to only assume that this kind of input is a UNIX file path if a UriKind of Absolute is specified?
Comment 3 marcos.henrich 2014-09-23 10:08:27 UTC
Hi David,

Thank you for the detailed bug report.

The pull request for this issue can be found in the link below.
Comment 4 marcos.henrich 2014-09-23 10:12:25 UTC
Fixed in master 84ab6a7833d8af7702e0359791ce8c4f754991a5.
Comment 5 marcos.henrich 2014-09-25 10:10:11 UTC
Changes were reverted by https://github.com/mono/mono/pull/1302

Marking issue as feature.
Comment 6 Marcin Floryan 2015-04-29 11:04:47 UTC
If this is not being fixed now, perhaps it should be removed from the release notes for version 3.12.0

Is there any plan to change this behaviour in the future? It appears to still be the case in 4.0.1
Comment 7 marcos.henrich 2015-08-29 07:58:13 UTC
@Marcin thanks, I updated 3.12.0 release notes.

There is a doc explaining why the UriKind.RelativeOrAbsolute cannot be fixed
along with a workaround.

Comment 8 Matt Z 2015-09-03 19:04:31 UTC
@marcos Sadly, that 3.12 workaround doesn't help with the vast majority of web frameworks already written, since it's opt-in behavior at the code level.

A much better approach would be to add a flag to the mono tool that enables the expected behavior for the entire process. That doesn't not require all existing code to implement mono-specific workarounds.
Comment 9 marcos.henrich 2015-09-04 02:33:17 UTC
Hi Matt,

Thanks for the feedback.
I created a pull request for a workaround that might help you in a future release.

Unfortunately I am not able to provide you any workaround that does this on 3.12.