-
Notifications
You must be signed in to change notification settings - Fork 4.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Uri] Does not allow $ in a hostname #36595
Comments
Tagging subscribers to this area: @dotnet/ncl |
I don't think I've ever seen that format of URL before. @MihaZupan do we have a validation bug? |
This seems like something we'll want to support; I recommend we triage this into the 5.0 milestone. |
https://devblogs.microsoft.com/commandline/whats-new-for-wsl-in-windows-10-version-1903/
Seems we already have special hostname validation just for UNC's. https://source.dot.net/#System.Private.Uri/System/UncNameHelper.cs,68 |
This kind of URLs have been around for a long time:
I'm surprised that they were never parsed by |
This is an issue with that part of a UNC path being the host - The validation fails in This stems from the fact that |
So, should |
It won't be becuase
|
@itodirel How come you are using |
I'm not going to speak for @itodirel, but I've built systems in the past that used URIs to specify actions.
Relative URIs were also used to add/override parameters. |
Regarding the question about why using System.Uri. It isn't my choice, and I can't change it easily. The dependency exists in MSBuild today, MSBuild will fail to load/build projects, because it uses System.Uri internally when it tries to build a project located on \\wsl$. CPS will fail to load projects, because internally it uses MSBuild for the evaluation, and for the same reason MSBuild uses System.Uri. Same with Visual Studio, the New Project Dialog, takes a dependency on System.Uri, and fails to create projects on \\wsl$. Do we want to tell all these folk to not use System.Uri? That would be a massive change, in code that might not been changed or touched for 20 years, or in legacy code, it can be done, with effort, but I'm trying to understand why can't System.Uri support it? Is it a bug in System.Uri? |
It might be reasonable to relax the hostname validation into just The ramification being that it would cause code to fail later rather than sooner if they try to feed a file host into a resolver, but that seems like a rare scenario? |
Is there a specification for UNC file names and allowed characters? We should likely comply with that. If $ is allowed, then it is technically a bug. A thing to consider for perspective is that it is a bug existing for 20 years -- either no one uses System.Uri with weird hostnames, or usage of $ in hostnames is extremely rare ... doesn't make it less severe for your scenario, but explains that it is a corner case not hit so far :( |
In this case, the $ is not part of the hostname. It's part of the path. `\hostname\share$' works:
Also,
|
I am confused. I understood the original report as |
|
Please note that in some examples above, the |
Also worth noting that Definition of URI from the RFC: https://tools.ietf.org/html/rfc3986#section-3
So while it may make sense to fix this one case of a I would suggest instead that a new factory method |
As noted offline, before going to far we probably want to understand whether this would help @itodirel anyway, given any change would almost surely only be in .NET Core. (He mentioned Visual Studio which still runs on .NET Framework.) |
Yes, but relative is more of a Uri string wrapper that doesn't provide much utility.
It's not valid because of the $ being in the host - If you don't think about it being in an implicit file form though, the format itself is not against the Uri spec - it's just a question of what kind of hostname rules are used. See #36595 (comment)
I am against this. If we decide this is something we would like to support, the question of allowing |
I am too 😄 |
Just a note that most of MSBuild's dependencies on this are inherited from System.Xml, like A fix would only systematically help VS if it was in Framework, though. |
I know nothing of MSBuild's use case of this scenario, but (I get that these types are usually created from factories, but those instances can maybe be wrapped in new custom |
Probably it's what MSBuild is feeding to the |
We've discussed this in triage:
|
Would it be worth asking the Microsoft owners of WSL to consider changing their choice of character? I get the |
File shares ending in |
@zivkan share names with |
@Eilon I'm meeting with WSL team on Friday, that's was actually one of my questions and asks to them, if anyone here wants to join us or come, please let me me know. |
Oops, sorry. Yes, I was totally mixed up. |
@itodirel I will follow up with you offline on the meeting. |
Based on offline discussion, WSL team is considering change of the name (as it violates spec). Closing for now, we can reopen and reconsider if things change in future. |
Thanks @karelz. I have met with the WSL team, they are open to changing the share name to work with System.Uri, they have a candidate for a new name, and are working on telemetry to validate that the new name does not conflict with other names. I will provide more updates here once I have them. |
@itodirel do you have an update to share? I will unlock meantime.😀 |
Oh looks like as of Windows 10 20175 they added support for This build should be getting generally released soon enough. (Edited: I thought this was coming in 21H1, I was wrong. Probably 21H2?) |
Issue Title
System.Uri cannot parse trailing $ sign in paths
General
We want to store and load data from WSL2 rootfs projection, which is exposed into Windows as "\\wsl$", we use this UNC path internally, to construct and manipulate the path. However, System.Uri cannot parse "\\wsl$" and throws a format exception:
System.UriFormatException: 'Invalid URI: The hostname could not be parsed.'
Example code and repro
var uri = new System.Uri(@"\\wsl$");
The text was updated successfully, but these errors were encountered: