json request --- returncode 400 on device --- emulator works fine

... once deployed to a Fenix 5X the end user receives a return code -400 when fetching some JSON data via a url from the device.

According to the docs, -400 maps to INVALID_HTTP_BODY_IN_NETWORK_RESPONSE

How can this be debugged further when the application functions as expected via the simulator

You can setup a proxy which simply logs the http traffic and forwards the request (I've used tcptunnel for this with http connections, you may need to add ngrok to the mix for https). What you want to do is see if you can find what is coming back in the response that is causing the device to reject it.

According to the docs, -400 maps to INVALID_HTTP_BODY_IN_NETWORK_RESPONSE


You can setup a proxy which simply logs the http traffic and forwards the request (I've used tcptunnel for this with http connections, you may need to add ngrok to the mix for https). What you want to do is see if you can find what is coming back in the response that is causing the device to reject it.

So - to be clear - the emulator handles the return data differently than the actual device?

Thanks for the response!

So - to be clear - the emulator handles the return data differently than the actual device?

It shouldn't, but given what you're seeing it sounds like it does. I'm trying to encourage you to check to see if there is some difference in the request that is sent or the response that is received; if there is one it may help the Garmin folks to determine what the actual problem is.

I recall a few months back a user got (I seem to recall) a -400 error with one of my widgets (I couldn't find the "contact developer" about it). But after trying a few things, it had something to do with a power saving mode on his phone. He turned it off, and things were fine. But I don't recall if it was iOS or Android, or what phone, what watch, etc. Could it be something like that? If your phone is using wifi does it work but not using the cell system, etc?

Any chance you were border-range distance from your phone or something?

It shouldn't, but given what you're seeing it sounds like it does. I'm trying to encourage you to check to see if there is some difference in the request that is sent or the response that is received; if there is one it may help the Garmin folks to determine what the actual problem is.

okey dokey --- used a proxy on my phone and capped the request and response ...

it looks like the emulator handles my url ok and actually hits:
http://query.yahooapis.com/v1/public/yql?q=SELECT%20*%20FROM%20atom%20WHERE%20url%3D%22http%3A%2F%2Fbeyondthewhiteboard.com%2Fgyms%2F4860-crossfit-threefold%2F2017%2Fmay%2F02.atom%22%20and%20id%20like%20'%25TrackEvent%25'&format=json

the watch actually CHANGES the url to (replaces the single quotes at the end with %27's) - which makes the call fail
http://query.yahooapis.com/v1/public/yql?q=SELECT%20*%20FROM%20atom%20WHERE%20url%3D%22http%3A%2F%2Fbeyondthewhiteboard.com%2Fgyms%2F4860-crossfit-threefold%2F2017%2Fapr%2F30.atom%22%20and%20id%20like%20%27%25TrackEvent%25%27&format=json

I changed the single quotes to double quotes (%22) and that is handled fine server side, however there is something else.

Definitely a bug in the watch (changing the url).

the url is actually being appended with a:
? HTTP/1.1

--- which is causing the call to fail as well (result is normally xformed to json, but with that appended to end of url by the watch, it's failing)!

see snippet here:
https://bitbucket.org/snippets/jay_colson/XLgBL

Has anyone noticed that the watch appends this to their URLs??

I recall a few months back a user got (I seem to recall) a -400 error with one of my widgets (I couldn't find the "contact developer" about it). But after trying a few things, it had something to do with a power saving mode on his phone. He turned it off, and things were fine. But I don't recall if it was iOS or Android, or what phone, what watch, etc. Could it be something like that? If your phone is using wifi does it work but not using the cell system, etc?

Any chance you were border-range distance from your phone or something?

Thanks for the clues, but it looks like the URL that I'm fetching is being 'modified' by the watch ... (see my other post) --- thanks, and any additional insight would be great!

I'm pretty sure you're running into the same problem as outlined in the first part of this post. Given the query you're trying to generate, it seems your code should look like this...

var url = "query.yahooapis.com/.../yql";

var params = {
"q" => "SELECT * FROM atom WHERE url=\"beyondthewhiteboard.com/.../02.atom\" and id like \"%TrackEvent%\"",
"format" => "json"
};

var options = {
};

Comm.makeWebRequest(url, params, options, self.method(:onWebResponse));


My guess is that you're generating the entire url string yourself, and that is exposing an inconsistency in the code that does the encoding of the url string. Could you provide the code where you generate the query so that I can file a bug.

yes - the code with the url is in the bitbucket snippet ( https://bitbucket.org/snippets/jay_colson/eLKzL/garmin-returncode-400 ) --- and you are correct, I am generating the url myself, not using the params.

Yeah, don't do that. Use the params parameter to makeWebRequest() so that they are properly urlencoded.

Travis