(same issue was previously described in https://forum.unified-automation.com/viewtopic.php?f=38&t=3519 )
The OPC server of our customer provides a discovery URI like this: opc.tcp://<host_ip>:<port>/some text with blanks
This results in the following error:
*** System.ArgumentException ***
Message: discoveryUrl
Parametername: URL does not appear to be valid.
StackTrace: bei UnifiedAutomation.UaClient.Discovery.BeginGetEndpoints(String discoveryUrl, String transportProfileUri, List`1 localeIds, List`1 profileUris, RequestSettings settings, AsyncCallback callback, Object userData)
bei UnifiedAutomation.UaClient.Discovery.GetEndpoints(String discoveryUrl)
Using Uri.EscapeUriString as recommended leads to a different error:
*** System.ArgumentException ***
Message: EndpointUrl is not a valid URL.
Parametername: remoteCertificate
StackTrace: bei UnifiedAutomation.UaBase.DefaultSecureChannel.CreateHello(String endpointUrl, MessageSecurityMode securityMode, String securityProfileUri, ICertificate remoteCertificate)
bei UnifiedAutomation.UaBase.DefaultTransportChannel.<OpenChannelAsync>d__55.MoveNext()
However, I can connect without issue using your UAExpert Client. Is there any fundamental difference in how the .NET Client SDK works vs. the implementation of the UAExpert Client? Or what do I need to do to make endpoint discovery in .NET SDK work the same as in the Client?
Blank space in discovery URL causes error - only with SDK
Moderator: uasdknet
-
- Full Member
- Posts: 7
- Joined: 08 Jun 2020, 13:06
-
- Full Member
- Posts: 7
- Joined: 08 Jun 2020, 13:06
Re: Blank space in discovery URL causes error - only with SDK
The issue was solved by changing the discovery URI on the serverside to contain no blanks.
An explanation about the exact proceedings in UAExpert Client vs. connecting through .NET SDK would still be helpful
An explanation about the exact proceedings in UAExpert Client vs. connecting through .NET SDK would still be helpful
- Support Team
- Hero Member
- Posts: 3064
- Joined: 18 Mar 2011, 15:09
Re: Blank space in discovery URL causes error - only with SDK
Hello,
the discovery URL (like other URL as well) should be a qualified URL, which means it should NOT contain characters that are not allowed to be used in an URL. That said, the .NET SDK is absolutely correct in rejecting the URL when containing "blank" characters (or having wrong format).
Other implementations may ignore errors in the discovery URL, and hence be able to connect to UA servers that provide non conformant discovery URLs. The parts of the URL that contain information desperately required for the client for doing connection establishment is the "hostname/IP" AND the "port", but not the optional "path" that may follow thereafter. UaExpert is parsing the URL and only extracts what is interesting for connection establishment (IP and port), everything else is just ignored. This strategy might be more robust when connection to a server that was configured badly. However, discovery URL is defined as being a valid URL (and not just some arbitraty string in a certain format), hence probing the URL with .NET framework function "IsValidURL()" before accepting and using it, is absolutely appropriate, and clearly points the finger to the (poor) server providing the non-conformant URL.
the discovery URL (like other URL as well) should be a qualified URL, which means it should NOT contain characters that are not allowed to be used in an URL. That said, the .NET SDK is absolutely correct in rejecting the URL when containing "blank" characters (or having wrong format).
Other implementations may ignore errors in the discovery URL, and hence be able to connect to UA servers that provide non conformant discovery URLs. The parts of the URL that contain information desperately required for the client for doing connection establishment is the "hostname/IP" AND the "port", but not the optional "path" that may follow thereafter. UaExpert is parsing the URL and only extracts what is interesting for connection establishment (IP and port), everything else is just ignored. This strategy might be more robust when connection to a server that was configured badly. However, discovery URL is defined as being a valid URL (and not just some arbitraty string in a certain format), hence probing the URL with .NET framework function "IsValidURL()" before accepting and using it, is absolutely appropriate, and clearly points the finger to the (poor) server providing the non-conformant URL.
Best regards
Unified Automation Support Team
Unified Automation Support Team