Ticket Created
over 1 year ago

CIQQA-1662

Bug report: ConnectIQ Api & web request via GCM iOS is not passing http response as plain text

Hello ConnectIQ team,

I use makeWebRequest to proceed an auth process of an oAuth API, where I have to read an bearer token from the WebAPI.

The API responds the token as a JSON value type string. It's not possible to read that value as JSON dictionary. But with the GarminConnect app on a Android phone it's possible to use the parameter HTTP_RESPONSE_CONTENT_TYPE_TEXT_PLAIN to get the http response as plain text to read the bearer token from.

With the GCM app on a iPhone it's not possible. The ConectIQ API returns error code -400 independent of the response type parameter.

As it's not possible to read JSON values from a application/json response body, it's necessary to be able to read the body as plain text and parse it in the app. That's the only possibility to handle WebAPIs not following the ConnectIQ rules.

Please add the possibility of reading plain text responses using the makeWebRequest parameter HTTP_RESPONSE_CONTENT_TYPE_TEXT_PLAIN on iOS platform like on Android.

Many thanks. That will help many developers dealing with WebAPIs which are not completely compatible to the ConnectIQ rules.

Referenze thead with examples:

https://forums.garmin.com/developer/connect-iq/f/discussion/310015/webrequest-how-to-ignore-wrong-response-content-type#pifragment-1298=2

Kind regards

Ronny Winkler

ronnywinkler
Parents
  • over 1 year ago

    -

    I don't know if or when it will get fixed. We have an internal document that lists out requirements for the behaviors given certain inputs, and as best I can tell it looks like the intent is that it would be forbidden for the responseType to be inconsistent with the response Content-Type header. I'm looking into this further, but that is what I'm reading.

    I've been asked to request the Connect and ConnectIQ app versions you are encountering the problem with. I'm assuming that is at least Connect 4.60.1, 4.61, 4.61.1, 4.62, 4.62.1, 4.62.2, and 4.62.3; ConnectIQ 2.19 and 2.20?

    As has been mentioned in other places, a possible workaround here is to use an intermediate service that will forward the request and then reformat the response as a JSON object. When I was developing apps, I successfully did this by propping up a small python service in AWS.

Comment
  • over 1 year ago

    -

    I don't know if or when it will get fixed. We have an internal document that lists out requirements for the behaviors given certain inputs, and as best I can tell it looks like the intent is that it would be forbidden for the responseType to be inconsistent with the response Content-Type header. I'm looking into this further, but that is what I'm reading.

    I've been asked to request the Connect and ConnectIQ app versions you are encountering the problem with. I'm assuming that is at least Connect 4.60.1, 4.61, 4.61.1, 4.62, 4.62.1, 4.62.2, and 4.62.3; ConnectIQ 2.19 and 2.20?

    As has been mentioned in other places, a possible workaround here is to use an intermediate service that will forward the request and then reformat the response as a JSON object. When I was developing apps, I successfully did this by propping up a small python service in AWS.

Children
  • over 1 year ago in reply to Travis.ConnectIQ

    Hi
    Thanks for the update.
    Yes I know I can do it using an external service. But I won't host paid services for a free widget. It cost already enough time to develop and maintain it :-)

    I can check the versions later. I habe an Android device where it works.
    I tested on a iOS device with the latest official Connect app from the app store.
    As SDK I used 4.1.5

    As I read the ConnectIQ manual, the options should define the expected content type. But if the SDK is focusing on the content typoe given in the response, wha is this parameter needed if I can't influence the result handling?
    As ConnectIQ if limited to JSON objects while there are many APIs using JSON string, numbers or something other, it's needed to get these responses into the widget as well.
    One solution would be to use the parameter Communications.HTTP_RESPONSE_CONTENT_TYPE_TEXT_PLAIN to force the SDK to provide the response body as plain text and the app can parse it as string.
    Another aproach can be that the SDK will wrap simple JSON values into a JSON object like {body: "JSON string"}. Then the app can handle it as a regular JSON object.

    It would be nice if can discuss in the development team. Many thanks in advance for your help.

    Kind regards
    Ronny