Simulator differences when handing non 200 response codes

When the simulator tries to download a HTTP_RESPONSE_CONTENT_TYPE_FIT workout and receives a non 200 response code it is passed back to the makeWebRequest callback, but on at least a 735xt the response appears to be flattened to a responseCode 0 in all cases.

This makes it hard to distinguish an expired authorisation from a server error or even a watch workout storage full

A similar (but different) case seems to occur with HTTP_RESPONSE_CONTENT_TYPE_JSON. If the server sends an error code back without setting media type then neither the simulator nor the 735xt see the code, but if the server sets the media type to JSON the simulator will see the response, but the 735 spams the request twenty more times then returns -300.

When I say "the 735" I appreciate I'm talking about (in my case) the ConnectIQ android app which is proxying the request, so there could well be a better place to report this, but as its biting my when running MonkeyC I'm going to put it here :)

Thanks

abs0d over 7 years ago

[I'm sure the forum hates me - I tried having this literal text just before the "Thanks" in my original post and it just threw up an error and refused to let me post. Anyway, here it is]

For the JSON case I'm going to experiment with having the server respond with a 200 in all cases and send the actual response code back as a JSON element (and hope the RESTful police don't notice me).

abs0d over 7 years ago

It works! Having the endpoint wrap the responseCode in a JSON object returned with a 200 response and then unwrapped by the app makes everything work fine.

I'm not entirely sure I should be happy about this...

I've just had an even worse thought. For the FIT case I could send back a faked up FIT file that wraps the response code and contains magic data that the app knows to recognise. There would only be two problems
a) I would be filling the user's device with very very strange data they would have to manually delete
b) I would probably have to beat myself senseless as a protective measure for the rest of humanity

So... no messing with the FIT download, but I have a JSON workaround for now - I'll probably have a query param from the client to specifically trigger it, in case we have another use for these endpoints I *really* don't want to have to explain how unsuccessful responses are sent...

travis.vitek over 7 years ago

The response code squashing has come up before. See this post.

Travis