Hi Dojo,
(Note: This appears to be related to the Response Error 6 question posted last year, although we are unable to implement the solution used on that question)
We have a use case for an HTTP connector where the URLs for POST requests contain the data in the URL rather than the body of the request. For example, the URL:
POST http://127.0.0.1:8888/api/v1/input/source/udp://10.10.10.10:4444
...will set the device's input source to udp://10.10.10.10:4444. Unfortunately, the device we're communicating with is unable to recognize and parse URLEncoded values, but rather relies on a full path as shown above.
It appears based on the results from Wireshark that the POST request isn't leaving DataMiner if the URL contains, essentially, another URL in its path. In Stream Viewer and the element log, the error is shown as:
Error : 6. [default]
Looking at the Development Library, I noticed that in Protocol.HTTP.Session.Connection.Request, it specifies the following:
If the specified value for the url attribute does not contain "://", then it is assumed that the provided value is a relative URL, and the URL will be constructed using the polling IP and port of the corresponding connection.
Could the mechanism for identifying a non-relative URL be preventing this request from being sent?
Any ideas on where to look for figuring this out are appreciated. Calling that endpoint directly from the QAction could work, although we would like to avoid that approach if possible.
Thanks.
Hi Nathan,
DataMiner will check if the request value contains "://" and if so, it assumes that the ip/hostname and port are provided. If not, it will add the ip/hostname and port of the corresponding connect to create the request URL. In your use case, if you would just provide "api/v1/input/source/udp://10.10.10.10:4444" in the url attribute, DataMiner would not add the ip/hostname port as it would wrongly assume that is was already present.
You could try creating the complete URL of the request in e.g. a QAction and save it in a parameter and then refer to that parameter via the Request@pid attribute. For example, <Request verb="POST" pid="1000">, where parameter 1000 would then contain the value http://127.0.0.1:8888/api/v1/input/source/udp://10.10.10.10:4444. Note that the parameter value includes the ip/hostname and port (To obtain the ip/hostname and port of the connection, you could use a parameter of type "ip" ).
Of course, this makes complete sense. I’ve tested this and it indeed solves the issue. Thanks.