iPhone makeWebRequest GET parameters stripped

Former Member over 5 years ago

After spending hours searching the forums, I believe I'm experiencing a unique makeWebRequest issue -- seemingly only on the iPhone (i.e. works on Android devices and the simulator). The call to makeWebRequest succeeds and my server returns a JSON object which my Watch Face receives (i.e. my onReceive response code is 200 and the data is a JSON object from my server - albeit empty of data). The options and parameters are shown below (a GET request and JSON response) and parameters are just Strings (base64 encoded options). The parameters are passed thru makeWebRequest's 2nd parameter and NOT included in my URL.

var options = {
	:method => Communications.HTTP_REQUEST_METHOD_GET,
	:headers => {"Content-Type" => Communications.REQUEST_CONTENT_TYPE_JSON},
    :responseType => Communications.HTTP_RESPONSE_CONTENT_TYPE_JSON
};

var params = {
    "request" => "[base 64 encoded string]",
    "token" => "[base 64 encoded string]"
};

So, the issue is that my server is not receiving any GET parameters from iPhones which results in empty JSON data being sent back. I've checked the raw server logs and access from Android phones and the simulator does receive GET parameters but from iPhones it doesn't. Somewhere between makeWebRequest and my server (I suspect either iPhone GCM or the iPhone itself) it appears that the parameters are being discarded.

The only other piece of information I can think of is that my server has a Let's Encrypt certificate -- if that makes a difference.

Anybody have any ideas or experiencing similar issues?

jim_m_58 over 5 years ago

I have a number of apps in the store that do gets, and never heard of an issue.

The thing I see that's odd is headers. I use

:headers => {"Content-Type" => Communications.REQUEST_CONTENT_TYPE_URL_ENCODED}

Former Member over 5 years ago in reply to jim_m_58

I'll give it a try and see if that works for me. Reading the documentation I was under the impression that Communications.REQUEST_CONTENT_TYPE_URL_ENCODED was meant to be used with HTTP_REQUEST_METHOD_POST and ...TYPE_JSON was meant to be used with ...METHOD_GET since those are the defaults and seem to align with most other documentation I've seen.

Out of curiosity, do you use POST or GET when you use URL_ENCODED?

jim_m_58 over 5 years ago in reply to Former Member

Only gets.

flowstate over 5 years ago in reply to Former Member

Well the docs for makeWebRequest() say this:

https://developer.garmin.com/downloads/connect-iq/monkey-c/doc/Toybox/Communications.html

:headers (Toybox::Lang::Dictionary) —

A Dictionary of HTTP headers to include in the request.

The “Content-Type” header for the body of the request can be specified using a REQUEST_CONTENT_TYPE_* value.
If the content type is not specified, it will default to “application/json” for GET and DELETE requests, and will default to “application/x-www-form-urlencoded” for POST and PUT requests.
By default, DELETE requests will have their parameters appended to the URL.
Setting the method as DELETE as well as a “Content-Type” header will result in the parameters being set in the body of the request and they will not be appended to the URL.
GET requests can only have their parameters appended to the URL, specifying the “Content-Type” header will not set the body.

So even though the content type for GET defaults to application/json, it doesn't seem like it will work very well if you have any parameters >_> . There might be some room for improvement here.

Former Member over 5 years ago in reply to flowstate

Thank you for the help! My GET request works now on iPhones by using :header "Content-Type" of REQUEST_CONTENT_TYPE_URL_ENCODED in conjunction with the a GET request.

I think there was some cognitive dissonance on my part (after reading some other posts on the forums which said putting GET parameters in the URL vs the params argument may cause problems), so I convinced myself that the last bullet in the documentation meant that GCM would process the makeWebRequest and append the 2nd argument (params) to the GET request (i.e. not required on my part).

And, in a way, that was reinforced by the fact that the simulator and Android devices either do exactly that (i.e. append the params to the url in GCM) or are included in the body of the request vs the iPhone app which does things just slightly differently.

Either way -- problem solved! Thanks again!