On 11 November 2015 at 17:43, Thomas Koster <[email protected]> wrote: > I am parsing a URL to connect to a WCF service. Try this: > > new Uri("net.tcp://guest:guest@myserver:12345"); > > I get a UriFormatException that complains about an invalid port > number. Uri.TryCreate is no better. > > It works if I remove the userinfo (credentials). It also works if I > don't use a scheme with a dot in it. I need both, however. > > As far as I can tell, this *is* a valid URI according to RFC 2396 and > RFC 3986. It works in Mono. It works in other languages. I think > .NET's URI parser is busted (Framework 4.5).
On 12 November 2015 at 10:32, Thomas Koster <[email protected]> wrote: > Using UriBuilder to create this Uri is also broken. Try this: > > var ub = new UriBuilder(); > ub.Scheme = "net.tcp"; > ub.UserName = "guest"; > ub.Password = "guest"; > ub.Host = "myserver"; > ub.Port = 12345; > > The Uri property getter for ub throws the same UriFormatException as above. On 12 November 2015 at 12:52, Mark Hurd <[email protected]> wrote: > Yeah, I tried a couple of variations on > > var ub = new UriBuilder("net+tcp://guest:guest@myserver:12345/") > ub.Scheme = "net.tcp" > > and ub.Uri property throws as you mention. On 12 November 2015 at 14:33, Thomas Koster <[email protected]> wrote: > This means UriBuilder is implementing the Uri property with something > silly like this: > > public Uri Uri > { > get > { > return new Uri(ToString()); > } > } > > This suspicion is confirmed by the reference sources[1]. > > The round-trip via string is wasteful and unnecessary and spreads the > parsing bug in Uri over the UriBuilder class as well. UriBuilder > should be able to trivially construct a Uri instance without parsing > or round-tripping via string. > > Speaking of reference sources, I had a quick scan over the parsing > code here[2]. OMG, it's thousands of lines of manual string twiddling, > like a kid with no comp sci education might have done. The cyclomatic > complexity must be astronomical. No wonder it's broken. > > [1] > http://referencesource.microsoft.com/#System/net/System/uribuilder.cs,b59ac7e3edbfe76c > [2] http://referencesource.microsoft.com/#System/net/System/URI.cs On 12 November 2015 at 16:07, Mark Hurd <[email protected]> wrote: > Yeah, note that NetPipeSyntaxFlags > > http://referencesource.microsoft.com/System/R/88aaba2e83d81ad0.html > > and thus NetTcpSyntaxFlags does not include UriSyntaxFlags.MayHaveUserInfo > > so, they intended to not allow user:password in these Uris, or it is a > large oversight. I see now that Microsoft has added additional syntax restrictions on the "net.tcp" URI scheme in its parser (the presence of the dot was a red herring). A careful read of RFC 3986 [4] says that this is okay, in principle. I concede that .NET's URI parser is somewhat justified in refusing to parse a "net.tcp" URI that has userinfo in its authority part. However, the exception message about an invalid port number is still incorrect. Also, Microsoft did not register "net.tcp" and its associated syntax restrictions with IANA [3] according to the procedure indicated by RFC 3986 [4] and BCP 35 [5]. That's okay, since registering with IANA is a big deal, but then "net.tcp" URIs should be parsed with the unrestricted general-purpose parser. There is now an interoperability issue with software that happens to use the "net.tcp" scheme for something completely different. Anyway, I guess I am going to have to store my credentials in separate configuration variables from the endpoint URL, just in case the binding is "net.tcp". [3] https://www.iana.org/assignments/uri-schemes/uri-schemes.txt [4] https://www.ietf.org/rfc/rfc3986.txt [5] https://tools.ietf.org/rfc/bcp/bcp35.txt -- Thomas Koster
