MakeWebRequest / JSON ==> Error -400 (INVALID_HTTP_BODY_IN_NETWORK_RESPONSE)

Former Member over 6 years ago

Hi

I have an app that makes a makeWebRequest to an HTTP server to get JSON Data. The current version (published) is working. I'm trying to make some changes but the call to makeWebRequest fails with error -400 (INVALID_HTTP_BODY_IN_NETWORK_RESPONSE) on the simulator.

I made some tests and finally find out that I only get this error if the HTTP Server returns "text/json; charset=UTF-8" as Content-Type. It woks if the server only says "text/json". Of course I can't change the server !

The "charset=UTF-8" raises the issue !...

I googled around but did not find any hint. Could someone help me ?

Here is the code I use :

[FONT=courier new]var params = {
                        "keyapp" => "xxxxxx", // API key
                        "dataFormat" => "json",
                        "id" => id
                   };

var headers = {
                // body will be encoded as 'a=1&b=2'
                "Content-Type" => Comm.REQUEST_CONTENT_TYPE_URL_ENCODED,

                // Force user agent
                "User-Agent" => UserAgent,

                // Accept encoding
                "Accept-Encoding" => "identity",

                // accept responses that are reported as json-compatible
                "Accept" => "application/json"
              };

var options = {
                :method => Comm.HTTP_REQUEST_METHOD_GET,
                :headers => headers,
                :responseType => Comm.HTTP_RESPONSE_CONTENT_TYPE_JSON
              };

Comm.makeWebRequest(
                        URL,
                        params,
                        options,
                        method(:onReceive)
                   );[/FONT]

Thanks !

FlowState over 6 years ago

To get around this kind of issue, I think your only option is to write a proxy, unfortunately.

jim_m_58 over 6 years ago

What happens if you take the "Accept" out of the headers?

They only thing I usually have in headers is the Content-Type, so maybe cut back to just that as a test.

F3b Software (Brian) over 6 years ago

The charset=utf-8 redundant since that is the default for JSON anyway.

Not sure what language you're using in your server code, if you're using PHP you can do something like this.
header('Content-Type:application/json); // do this to force to application/json
//header('Content-Type:text/json); //or test/json without the charset tag
header("HTTP/1.1 200 OK");

FlowState over 6 years ago

I think the OP does not control the server, hence the suggestion to write a proxy.

I will add that “application/json” is the correct content type for JSON, and as noted on the forums a few times, “text/json” may work for Bluetooth requests, but for music-enabled watches that support CIQ network requests over WiFi, the “application/json” content-type must be received for JSON content or Wi-Fi requests will fail.

So even if the server were to stop sending the charset, “text/json” is still wrong and would still fail for certain watches (music-enabled) and certain situations (Wi-Fi requests). I believe you can test the wifi “path” by running your app in a music watch in the simulator, like 645 music.

Former Member over 6 years ago

Hi
Actually I don't control the server but the proxy is not a solution as there is a limit rate on a per-IP basis :-(
Sounds like a ConnectIQ bug :-(((
Regards

jim_m_58 over 6 years ago

Have you tried changing the headers in your code? Commenting out the "Accept" to start with to see if you still get the error?

FlowState over 6 years ago

Whether the failure on “charset” is a bug or not, the server is still returning “text/json” for JSON which is wrong (it should be application/json), and it will still fail for WiFi on music devices, which doesn’t seem like behaviour that is going to change in CIQ. And even if the charset behaviour was fixed, there’s no guarantee that older devices would change. :/

Have you contacted the owners of the server? Maybe they can help you.

jim_m_58 over 6 years ago

Music devices are very rarely connected to wifi (only downloading music or syncing). It's actually hard to try a ciq app using wifi on those.

You can also use connectionInfo to only do things if connected to a phone, so it's avoidable.
for the va3 Music LTE, it doesn't have wifi, but does have LTE, so a similar check could be done there (LTE will be connected much of the time, I imagine)