WebRequest: How to ignore wrong response content type?

Im using a WebAPI from a widget. One of these requests is a authenticate request passing an auth token and the response is returning an bearer token.

The problem is, that the response it using "content-type: application/json" as responde header, but the body is plain text. I filled the options with this setting to force a plain text response.

        var options = {
            :responseType => Communications.HTTP_RESPONSE_CONTENT_TYPE_TEXT_PLAIN,
            :method => Communications.HTTP_REQUEST_METHOD_POST,
            :headers => {
                "Content-Type" => Communications.REQUEST_CONTENT_TYPE_URL_ENCODED,
                "Authorization" => "Bearer "+ mAccessToken
            }

That is working on a fenix 5xplus, but on fenix6, fenix7 or Epix, a responsecode -400 is returned instead.

Can I somehow ignore that content check? It's fine if Garmin wants to help to check for corrent type, but in this case it's very frustrating. I can't change the WebAPI and I cant get the Garmin API to use my given option as content type.

How can I solve this problem?

Edit:
I got answer from the WebAPI owner:
The body is a valid JSON (string).
So my question is:
Why am I getting an -400 error when using JSON as result content-type?

        var options = {
            :responseType => Communications.HTTP_RESPONSE_CONTENT_TYPE_JSON,
            :method => Communications.HTTP_REQUEST_METHOD_POST,
            :headers => {
                "Content-Type" => Communications.REQUEST_CONTENT_TYPE_URL_ENCODED,
                "Authorization" => "Bearer "+ mAccessToken
            }

Response body:

"eyJhbGciOiJSUzUxMiIsI..."

Travis.ConnectIQ: Is this an expected error or is it a bug? Shouln't the data result be teh parsed string when using HTTP_RESPONSE_CONTENT_TYPE_JSON?

Edit:
I'm wondering if this is an error which only is present in the simulator.
It seems, that the JSON string is parsed correct in the device with option HTTP_RESPONSE_CONTENT_TYPE_JSON.
But it returns an error -400 in simulator.

I made a fallback function if JSON option results in -400 error to try again with option HTTP_RESPONSE_CONTENT_TYPE_TEXT_PLAIN to get it workin in simulator. But that's a bit ugly.
Could this someone from Garmin please test and confirm? Many thanks!

0 Travis.ConnectIQ over 3 years ago

The body is a valid JSON (string).

The result you show is a valid JSON value, but we expect a valid JSON object. Yes, many web service APIs return JSON values (string, number, array, object true, false, or null), but we require the result to be a JSON object if you tell use the response content type is JSON.

As you have discovered, we will provide direct access to the content as a String if you can convince the VM to accept the content as TEXT.

0 ronnywinkler over 3 years ago

Travis.ConnectIQ said:
As you have discovered, we will provide direct access to the content as a String if you can convince the VM to accept the content as TEXT.

Hi Travis, thanks for your answer.
How can I access the content as text? Using HTTP_RESPONSE_CONTENT_TYPE_TEXT_PLAIN it works in simulator and on the Fenix5, but on Fenix6/7 or Epix users are getting -400 error. I thinks it's caused by the response content-type header. Is there a common way to get plain text independent of response header on every device?

If a dictionary object is needed as response object (for callback function), then the VM could simply return an object like {"body"=> "body content..."} for JSON string http body "body content...".
I know what I expect and this way it could be a very simple access to such simple JSON values.

0 ronnywinkler over 3 years ago in reply to Travis.ConnectIQ

Hello Travis.ConnectIQ

do you have a suggestion to solve this problem? I can't see how a device is handling this JSON value until I (or better the user) get the error.
The older devices seem so be more flexible. But newer ones (and the main target devices) not. All new firmwares seem so make problems in that case.

And this JSON strings are common for oAuth and auth token responses. So this is a essential API request, which makes my widget useless for most devices.

At least ist should be possible on ALL devices to force the VM to pass the response as it is as plain text and give the app the control to parse it.

But on a fenix7s (I can use for some tests), it's not accepting as JSON and it's not accepting as text/plain. It seems it ignores the option parameter or it raises the -400 error because it doen't fit to the response header. I just would like to set the response content type in the options and want the device to ignore the header field in that case.

I hope for a little bit of help and alternatives

0 flowstate over 3 years ago in reply to ronnywinkler

I know this isn't the answer anyone wants to hear, but I think the only solution here is to run your own proxy service which massages either the response data and/or the headers into a format which the watch will accept.

0 _psx_ over 3 years ago in reply to ronnywinkler

Shouldn't you ever use makeOAuthRequest instead of makeRequest?

0 ronnywinkler over 3 years ago in reply to flowstate

I don't have the ressources for such things. I just developed a widget for a smarthome hub and sitting now between the chairs...

0 ronnywinkler over 3 years ago in reply to _psx_

The makeOAuthRequest starts before (get oAuth token, get auth/refresh token).

Then I need a login token for the target device and a bearer token for the session. That's where I only get a Json string with the token.

0 ronnywinkler over 3 years ago in reply to flowstate

Hi flowstate,

is it possible to use a proxy server for makeWebRequest? I'm wondering if it's possible to use a proxy server where the header field content-type can be manipulated for the response.

But it has to be a proxy server, because the target url is different based on the target device. It's something like id.api.com So I can't use a 1:1 forwarding.

0 jim_m_58 over 3 years ago in reply to ronnywinkler

With the device that works and those that don't are you all using the same GCM? Are you on Android and the ones that fail iOS or v/v?

0 ronnywinkler over 3 years ago in reply to jim_m_58

jim_m_58 said:
With the device that works and those that don't are you all using the same GCM? Are you on Android and the ones that fail iOS or v/v?

Good question.
I use a fenix 5x+ with Android and that works.
I tested with a fenix 7s with iOs and that doesn't.

But as Travis mentioned, the VM on the device is checking the result/content-type, or not?