need debug help on actual CIQ3 device

i have a CIQ3 app that connects to a web service (not my service) and users have reported it doesn't work. unfortunately i don't have a CIQ3 device myself, so have only tested on the simulator, which works... Coleman has suggested I reach out here to see if someone can help me debug it - i.e., run it on a CIQ3 device (I will provide login info to setup the app) and send me log output from the device. potentially iterate until I can get it working... if you are up for this send me a PM in this forum.
thanks in advance

jim_m_58 over 6 years ago

Log file sent....

Horsetooth over 6 years ago

thanks for your help Jim. it turns out the problem here doesn't have to do with CIQ3, but is that i am trying to use a server (which i cannot change) that requires a POST http request with url-encoded parameters but the request that goes out from connect IQ turns out to be putting the parameters in the POST body instead of the url.

the documentation says:

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.

so, it looks like it really shouldn't be doing this - is this a bug or is the doc wrong?

Horsetooth over 6 years ago

... and it works in the simulator because the simulator allows the parameters to be included in the makeWebRequest URL, instead of params, but the devices do not.

Travis.ConnectIQ over 6 years ago

It isn't clear to me exactly what the issue is... It sounds like the service you are working with expects a POST request with parameters included in the query-string part of the URL, and we are sending the params as the url-encoded request body. Is that correct?

As far as I understand, GET parameters are to be encoded in the URL and POST parameters are written to the request body. When issuing a POST you are providing data to the service, so it doesn't make sense to put information into the query-string part of the URL. It sounds like the service you're accessing is doing something that violates the HTTP spec. I'll have to find the section that says this is the case...

Horsetooth over 6 years ago

yeah, that about sums it up - the server has been around for a long time so may be violating the spec but its not going to change. It only accepts POST, not GET unfortunately.

why do the devices fail when the parameters are pre-included in the url string (and why doesn't the simulator?)

Horsetooth over 6 years ago

not definitive, but at least according to the person who answered this question its valid: https://stackoverflow.com/questions/14710061/is-it-valid-to-combine-a-form-post-with-a-query-string/14710450

Travis.ConnectIQ over 6 years ago

This is because the code that does the web request processing in the simulator is not the same as that on the devices. The ConnectIQ simulator tries to emulate the device behavior as closely as possible.. unfortunately we probably don't have tests for pathological cases like this one.

I've added a note to file a bug report to make the simulator consistent with devices for this case.

Horsetooth over 6 years ago in reply to Travis.ConnectIQ

hi Travis, i asked in the old forum messages but not sure you'll see them:

is there a way to link to this issue (supporting POST w/query params)? I'm asked about this from users regularly, since going directly to dexcom share servers would be an easier setup. I know Fitbit supports it (with 3rd party apps now, and official support soon probably), and Wahoo is also working directly with dexcom and cycling Team Novo for direct access on Wahoo bike computers.