• Replies 7 replies
  • Subscribers 18 subscribers
  • Views 319 views
  • Users 0 members are here
Options
Related

makewebrequest returns -400 on json string

Fsallstrom

Hi, I use makeWebRequest to fect data from a web server on Internet. It consistently returns -400 (Response body data is invalid for the request type.), It seems QIC doesn't like the format of the response I get from the web server. When looking at the HTTP log in the simulator I see this:

It looks like I get a valid json string in the response body. 

here is my makewebrequest code:

var headers = { 
			"Content-Type" => Comms.REQUEST_CONTENT_TYPE_JSON };
	
		var params = {
			"password" => password,
			"accountName" => username,
			"applicationId" => "d89443d2-327c-4a6f-89e5-496bbb0317db" };
		
		var options = { 
			:method => Comms.HTTP_REQUEST_METHOD_POST,
			:responseType => Comms.HTTP_RESPONSE_CONTENT_TYPE_JSON,
			:headers => headers };	
		
		Comms.makeWebRequest(my_URL, params, options, new Lang.Method(self, :getResponse));
 

Right now I have to put in a web proxy in between the Garmin client and the web server, to re-format the response to a json dictionary, like so: {"responseData" => "231fsddf-21sdfs3-2fsdf3-23dfs1"}.

Obviously that adds a lot of complexity and cost to my solution, why does not CIQ accept the json response from the web server directly? 

thank you in advance!

  • CIQ converts json into a dictionary, and therefore will only accept an object and not things like strings that you show in your trace.

    But what I think you may be able to do here is to set the response type to HTTP_RESPONSE_CONTENT_TYPE_TEXT_PLAIN and it may return you the raw data even though the response type returned is actually json. In your case this should not be too complicated as you just have a single string. More complex data would require more work.

    Note, I have not tried this in a very long time and I seem to remember differences between how the simulator handled the mismatch and how a real device did.

  • in reply to gasteropod

    Thank you for your quick response  . I had tested to use HTTP_RESPONSE_CONTENT_TYPE_TEXT_PLAIN before but it didn't work on target. I did a new test just now on an Epix gen 2 and it seems to work. Something must have changed since I tried it last time. Very good news. I need to do some more testing but based on the early test results it seems CIQ can accept top level json strings if content type is set to plain text.

  • in reply to Fsallstrom

    Unfortunately there is some inconsistency on how CIQ handles this. It works in the sim and on my Epix gen 2 device, but not on a CIQ 3.3 device (Fenix 5x plus). I have filed this as a bug and will update the bug report with my findings 

  • in reply to Fsallstrom

    Yes, I feared it might not be something you could rely on.

  • in reply to gasteropod

    bummer. I would really like to not have a web proxy in between the web server and the garmin client. It creates a ton of complexity and adds cost to my solution. Top level strings are standardized and valid JSOn response types, so this should considered a CIQ bug. 

  • in reply to Fsallstrom

    I don't disagree, but if you look through the bugs forum, you will find many unfixed bugs. And I'd be amazed if Garmin would update firmware on older watches such as the fenix 5 which I'm sure would be required to fix this.

  • in reply to gasteropod

    Yes, I think you're right. If I only knew which devices that works vs not, then at least i could make a decision whether to exclude support for older devices or not. Problem is I have to test on target to find out