Could this be an Indy Error?

[Dwest 0]

This is kind of a longshot, but the company I work for is upgrading from Delphi 10.3.3 to Delphi 12. We use a mapping program that was created in-house. It can map up to 100 different points, and optimize for drivetime and mileage. To accomplish this, it puts all of the coordinates of the 100 points into a URL, then returns back with the output of that URL (X number of map points, in optimized order). For testing, we made it return the URL to a txt file, and then the output to a separate txt file. In 10.3.3, the output txt file returns coordinate sets for all of the mapped points. In 12, it returns errors. Originally, we thought it could be a mapping service API error, except when the Input URL (generated by Delphi 12) is entered in google chrome, it returns back correctly. The code between the 2 versions is copy-paste. We are thinking it could be a version issue, so I am looking to see if the code for the HTTP component may have changed between version 10.3.3 and version 12 of Delphi. Can you help? I don't have direct access to the exact error that we are receiving, but I'm sure I can get it.

[Lajos Juhász 293]

This is really not enough information to help you. You should post some code and the error messages that you recieve.

[Dwest 0]

The exact error message that is being received is....

{"results":null,"errors":["Coordinate with id 0 is not valid. Please check separators. Error ID: 6d5d190c-5024-4152-9d81-bee145224322"],"processingTimeDesc":null,"responseCode":"400","warnings":null,"requestId":null}

 

I can't give the proper input, as it is real-world locations of people I do not have the appropriate permissions to post, but here is the input modified to remove those coordinates, as well as our API Key.

https://wps.hereapi.com/2/findsequence.json?&apiKey={OUR API KEY}&start=0;{COORD1}&destination1=1;{COORD2}&destination2=2;{COORD3}&destination3=3;{COORD4}&destination4=4;{COORD5}&destination5=5;{COORD6}&improveFor=time&routeAttributes=summary&mode=fastest;car;traffic:disabled;

 

Edit: Unfortunately, I cannot post any of the code, if this is insufficient, then I understand.

Edited January 18 by Dwest

[Remy Lebeau 1397]

2 hours ago, Dwest said:

To accomplish this, it puts all of the coordinates of the 100 points into a URL

Depending on the length of the data, and just how many points are being sent, I probably would not have used the URL for that.  WebServers tend to limit how much data can be sent in a URL query string.  A POST body might have made more sense.

2 hours ago, Dwest said:

For testing, we made it return the URL to a txt file, and then the output to a separate txt file. In 10.3.3, the output txt file returns coordinate sets for all of the mapped points. In 12, it returns errors. Originally, we thought it could be a mapping service API error, except when the Input URL (generated by Delphi 12) is entered in google chrome, it returns back correctly.

Did you try comparing Chrome's raw HTTP request/response data to TIdHTTP's raw HTTP request/response data for differences?  You can use Chrome's built-in debugger to get the HTTP data it exchanges over the wire, and you can attach a TIdLog... component to the TIdHTTP.Intercept property to get the HTTP data it exchanges over the wire.

2 hours ago, Dwest said:

The code between the 2 versions is copy-paste. We are thinking it could be a version issue, so I am looking to see if the code for the HTTP component may have changed between version 10.3.3 and version 12 of Delphi.

There were a handful of checkins for TIdHTTP between those 2 versions, but offhand I don't see anything that would affect what you describe.

2 hours ago, Dwest said:

The exact error message that is being received is....

{"results":null,"errors":["Coordinate with id 0 is not valid. Please check separators. Error ID: 6d5d190c-5024-4152-9d81-bee145224322"],"processingTimeDesc":null,"responseCode":"400","warnings":null,"requestId":null}

Offhand, the first thing that comes to mind is the formatting of {COORD1}, {COORD2}, etc.  What does that actually look like? (without revealing real numbers. Can you use fake numbers?) The error message says to check the separators, do the coordinates have their own separators in them?  If so, are you perhaps using locale-based separators in the formatting?

Edited January 18 by Remy Lebeau

[Dwest 0]

58 minutes ago, Remy Lebeau said:

Depending on the length of the data, and just how many points are being sent, I probably would not have used the URL for that.  WebServers tend to limit how much data can be sent in a URL query string.  A POST body might have made more sense.

Typically, it's anywhere from 2-65 different map coordinates. Sometimes as high as 98.

1 hour ago, Remy Lebeau said:

Did you try comparing Chrome's raw HTTP request/response data to TIdHTTP's raw HTTP request/response data for differences?  You can use Chrome's built-in debugger to get the HTTP data it exchanges over the wire, and you can attach a TIdLog... component to the TIdHTTP.Intercept property to get the HTTP data it exchanges over the wire.

Yes we did every comparison we could think of, I don't think the person in charge of this used chrome's debugger, So I will mention it as an option.

1 hour ago, Remy Lebeau said:

Offhand, the first thing that comes to mind is the formatting of {COORD1}, {COORD2}, etc.  What does that actually look like? (without revealing real numbers. Can you use fake numbers?) The error message says to check the separators, do the coordinates have their own separators in them?  If so, are you perhaps using locale-based separators in the formatting?

Of course, the formatting is as such: 99.4698149,-99.8852148

For each coordinate. (All I did to modify was change the first numbers to 9) ex: 

start=0;99.4698149,-99.8852148&destination1=1;99.4698149,-99.8852148&destination2=2;     etc...

[Tom F 83]

3 hours ago, Dwest said:

I can't give the proper input, as it is real-world locations of people I do not have the appropriate permissions to post, but here is the input modified to remove those coordinates, as well as our API Key.

https://wps.hereapi.com/2/findsequence.json?&apiKey={OUR API KEY}&start=0;{COORD1}&destination1=1;{COORD2}&destination2=2;{COORD3}&destination3=3;{COORD4}&destination4=4;{COORD5}&destination5=5;{COORD6}&improveFor=time&routeAttributes=summary&mode=fastest;car;traffic:disabled;

 

Why didn't you edit the input, changing the coordinates so that there is no confidentional information?

[Dwest 0]

27 minutes ago, Tom F said:

Why didn't you edit the input, changing the coordinates so that there is no confidentional information?

This is what it looks like

 

https://wps.hereapi.com/2/findsequence.json?&apiKey={OUR API KEY}&start=0;99.4698149,-99.8852148&destination1=1;99.4698149,-99.8852148&destination2=2;99.4698149,-99.8852148&destination3=3;99.4698149,-99.8852148&destination4=4;99.4698149,-99.8852148&end=5;99.4698149,-99.8852148&improveFor=time&routeAttributes=summary&mode=fastest;car;traffic:disabled;

 

I have experimented with the separator's a bit within the coordinates and between and nothing seems to work. HERE's map service API documents tell us to construct the link in this way.

1 hour ago, Remy Lebeau said:

The error message says to check the separators, do the coordinates have their own separators in them?  If so, are you perhaps using locale-based separators in the formatting?

Also, to add to my previous comment, the separators don't seem to be the issue when putting it into a browser. Since it works just fine that way.

 

My boss seems to think it may be some sort of security issue with the program communicating with the API since it works in the browser and throws errors in the program.

Edited January 18 by Dwest

[Remy Lebeau 1397]

1 hour ago, Dwest said:

My boss seems to think it may be some sort of security issue with the program communicating with the API since it works in the browser and throws errors in the program.

If you can ensure the submitted data is absolutely identical in both browser and Indy, then the only thing I can think of is if the server is sensitive to the User-Agent that is making the request.  Some webservers change their behavior depending on which browser is asking, and it is not uncommon for webservers to behave weird/incorrect when encountering Indy's default User-Agent.  Try setting the TIdHTTP.Request.UserAgent property to mimic Chrome, see if that makes any difference.

[B4Him 0]

I am having the exact error trying to use Here API in Delphi 12.  In Delphi 11 the http get url works fine.  When I use the exact same url with coordinates and code in Delph 12 I get the exact error you describe.  It happens with indy http and TNetHttpClient components. 

Just as you describe, the url works from Chrome and Edge but returns the error from the Delphi 12 app.

I have been fighting with this for days.  Have you found a solution?

Edited January 18 by B4Him

[Remy Lebeau 1397]

6 hours ago, B4Him said:

When I use the exact same url with coordinates and code in Delph 12 I get the exact error you describe.  It happens with indy http and TNetHttpClient components.

That sounds more like a server-side issue, if it affects both components. Did you check if the requests are different in any way between Delphi 11 vs 12?