HTTP codes

To be clear, you should only get negative codes (the ConnectIQ codes you're referring to) if an error occurs.

Without more details on the actual problem you were seeing, it is difficult to tell what you should expect the behavior to be (both on devices and in the simulator). Typically apps will see -400 in the simulator because the server is sending an HTTP Content-Type header that conflicts with the :responseType option that was provided to makeWebRequest AND the WiFi option in the Connection menu is enabled. In this particular case, there are multiple issues at play:

1. The simulator is allowing access to WiFi for normal requests, when this doesn't typically happen on most devices (it does happen on some edge devices, but not on wearables like the fenix/forerunner)
2. The WiFi code expects the :responseType parameter to match up with the Content-Type header in the response. If they don't match up, then it won't work.
3. The server is sending a Content-Type header that doesn't accurately describe the data. This often happens when the server sends back text/plain for data that is actually application/json or similar.

The first issue is something that I worked on recently, and it should be fixed in an upcoming SDK. The second issue is something that I've worked on also, but we're not ready for that one yet as it requires our fix and then additional fixes to other products to get things working consistently.

If you were running into some other issue, then maybe you can provide some more detail and I can tell you what the expected behavior should be.

Hi Travis, thanks for the reply. In this instance the response should generate an error since there is no body for the response. This cased some confusion a while ago and led to me becoming familiar with the -4xx errors, it was probably you that responded to me on that previous thread! The simulator continues to give the error, while the watch returns a 201 response directly from the real response. I was just curious whether this behaviour had changed - it's not causing me problems since the event hub app does a fire and forget of data into a streaming service and doesn't care about success other than showing a status to the user. I'm simply reporting both codes as "OK" now since both seem to be potentials for normal responses.

Ahh, okay.

We have an issue in the backlog to verify behavior between the simulator and devices (using both GCM/iOS and GCM/Android) is consistent for makeWebRequest. It should cover some of these unusual cases.

Our suggested behavior is to allow responses that have a Content-Length header with the value 0 to be handled by passing the HTTP status code and null to the response callback. As you've seen this isn't being followed, but it is the direction we are trying to go.

Cool that all sounds good. I consider this extremely low priority though, considering all the other cool stuff being worked on so I think the team definitely have the right priorities :)