makeWebRequest working in sim, failing on physical device. (error: -400)

Oops, this is more like the code.

var options = 
        {
           	:method => Communications.HTTP_REQUEST_METHOD_GET,
           	:responseType => Communications.HTTP_RESPONSE_CONTENT_TYPE_TEXT_PLAIN
       	};
       	
    Communications.makeWebRequest("https://labs.bible.org/api/", {"passage"=>"John%203:16"}, options, method(:onReceive));

Thanks in advance!

Are you seeing the error with Android or iOS?  What if instead of the %20 you use a space?

-400 occurs on both Android and iOS.  I tried using a space instead, but it still doesn't work.

Are you using a device that supports plain text?

From the API doc:

HTTP_RESPONSE_CONTENT_TYPE_TEXT_PLAIN = 5

I'm fairly certain that the issue is coming up because the response you're getting indicates that the Content-Type does not match the Content-Type you describe with the request. You are setting :responseType to HTTP_RESPONSE_CONTENT_TYPE_TEXT_PLAIN (an alias for text/plain used by ConnectIQ), but the server is sending back a response with the following headers:

< HTTP/1.1 200 OK
< Date: Thu, 05 Mar 2020 22:34:53 GMT
< Server: Apache/2.4.18 (Ubuntu)
< Vary: Accept-Encoding
< Content-Length: 160
< Content-Type: text/html; charset=UTF-8

Either GCM or the device firmware is seeing this as a mismatch, and is failing. This type of issue has been around for a long time. We have had an issue filed to fix this and several other inconsistencies between the various parts of the platform (GCM iOS/GCM Android/WiFi/LTE/Simulator), but it hasn't gotten the attention it deserves.

I believe that, as of the last time I checked this, this problem didn't exist for requests being sent over BLE. I have a patch that should resolve the issue for the WiFi code path (in the simulator and on devices), but it can't be merged until we establish and document the expected behaviors internally (so we can get consistent behavior across product areas).

That said, what device(s) are you seeing this problem on?

I looked at the service for a bit, and it looks like they offer JSON and TEXT format output, but they send conflicting headers with both. For the time being, the easiest solution is to setup a proxy service that would receive the request, forward it, and then re-format the response with the expected headers.

I used a service hosted on Google for some time. The free limits are fairly generous; I never exceeded the limit or had to pay a penny for running this service for over five years.

Thanks so much guys! I'm using a Vivoactive 3. I plan to do some research soon and figure out if a proxy service is the best thing for me.  Again, thanks so much for your quick responses!

Hi SirLanceLot, I am having the exact same problem and was wondering if you ever managed to find a work-around for it? 

Best regards

Fredrik

Hi! 

Yes, I did eventually figure out how to get around this. Apparently I had defined the “wrong” header with my request, but since the website sent conflicting headers, I was unable to use that website. This will not crash the sim, but always crashes the device. I attempted to set up a proxy, but that was way over my head. I ended up just changing the website I was using.

One thing that really confused me, though, is the fact that parameters (anything after the ? in a url) need to go in the special parameters section. You probably already knew that, but I just wanted to make sure. 

I hope this helped!

SirLanceLot

Thanks, yes building a proxy feels a bit over my head as well so hope I can avoid it. I don't really have an option to change the website so I am stuck with whatever it sends me. It seems ts does not send a perfectly correct JSON formatted string, but the sim seems to cope with, as do other device platforms to my knowledge. I wish there was a way to receive a response in "raw format" I don't mind doing the parsing needed, as long as I get the data to my app.