Announcement

Collapse
No announcement yet.

makeWebRequest() regression in 2.3.X SDK *nix simulator

Collapse
X
  • Time
  • Show
Clear All
new posts

  • makeWebRequest() regression in 2.3.X SDK *nix simulator

    I'm seeing all Communications.makeWebRequest() calls fail with 404 in the Mac & Linux simulators for 2.3.X.

    Works under windows and on a watch in 2.3.X, and seems to work fine on all platforms for 2.2.x

    Very simple to demonstrate in an app - link to demo app attached

    Anyone else seeing this?

    David
    GarminWebRequestTest - Simple app to demonstrate makeWebRequest() regression in Garmin ConnectIQ 2.3.X SDK *nix simulator

  • #2
    Could you just post the few lines involved in the makeWebRequest? (it's a bit tricky these days)

    There has been something similar in the past with using an iphone on the watch, and what it involved - if I recall - how the parameters were specified. If you do it in the URL, you got a 404, but if you specified them as the parameters dictionary to the call, it worked fine.
    My Connect IQ Apps in the Store
    Facebook - Instagram -
    Twitter

    Comment


    • #3
      Originally posted by jim_m_58 View Post
      Could you just post the few lines involved in the makeWebRequest? (it's a bit tricky these days)

      There has been something similar in the past with using an iphone on the watch, and what it involved - if I recall - how the parameters were specified. If you do it in the URL, you got a 404, but if you specified them as the parameters dictionary to the call, it worked fine.
      The minimal fragment would be:
      Code:
      const URL = "https://www.garmin.com";
      
      var params = {                                              // set the parameters       
            "definedParams" => "123456789abcdefg"        
      };       
      
      var options = {                                             // set the options       
         :method => Communications.HTTP_REQUEST_METHOD_GET,      // set HTTP method        
         :headers => {                                           // set headers        
                 "Content-Type" => Communications.REQUEST_CONTENT_TYPE_URL_ENCODED},        
                                                                 // set response type        
         :responseType => Communications.HTTP_RESPONSE_CONTENT_TYPE_URL_ENCODED        
      };       
      
      var responseCallback = method(:onReceive);                  // set responseCallback to       
                                                                 // onReceive() method        
      // Make the Communications.makeWebRequest() call       
      Communications.makeWebRequest(URL, params, options, method(:onReceive));
      I copied the example from https://developer.garmin.com/downloa...nstance_method

      and the rest of the code with the callback is at https://github.com/abs0/GarminWebReq...uestTestApp.mc

      What is most puzzling is it works fine under SDK 2.3.x on Windows and the watch.

      I tried changing/adding/removing options and params, and specifying directly as call params rather than named variables, but didn't manage to change the behaviour.

      Thanks

      David

      Comment


      • #4
        I believe the equivalent of that request can be executed from the command line...

        Code:
        $ curl -v --header "Content-Type: application/x-www-form-urlencoded" https://www.garmin.com/?definedParams=123456789abcdefg
        * Hostname was NOT found in DNS cache
        *   Trying 23.206.120.208...
        * Connected to www.garmin.com
        * successfully set certificate verify locations:
        *   CAfile: none
          CApath: / etc/ssl/certs
        * SSLv3, TLS handshake, Client hello (1):
        * SSLv3, TLS handshake, Server hello (2):
        * SSLv3, TLS handshake, CERT (11):
        * SSLv3, TLS handshake, Server key exchange (12):
        * SSLv3, TLS handshake, Server finished (14):
        * SSLv3, TLS handshake, Client key exchange (16):
        * SSLv3, TLS change cipher, Client hello (1):
        * SSLv3, TLS handshake, Finished (20):
        * SSLv3, TLS change cipher, Client hello (1):
        * SSLv3, TLS handshake, Finished (20):
        * SSL connection using ECDHE-RSA-AES256-GCM-SHA384
        * Server certificate:
        *      subject: C=US; ST=Kansas; L=Olathe; O=Garmin International; OU=Information Technology; CN=*.garmin.com
        *      start date: 2017-06-21 00:00:00 GMT
        *      expire date: 2018-09-20 23:59:59 GMT
        *      subjectAltName: www.garmin.com matched
        *      issuer: C=US; O=Symantec Corporation; OU=Symantec Trust Network; CN=Symantec Class 3 Secure Server CA - G4
        *      SSL certificate verify ok.
        > GET /?definedParams=123456789abcdefg HTTP/1.1
        > User-Agent: curl/7.35.0
        > Host: www.garmin.com
        > Accept: */*
        > Content-Type: application/x-www-form-urlencoded
        > 
        < HTTP/1.1 302 Moved Temporarily
        * Server AkamaiGHost is not blacklisted
        < Server: AkamaiGHost
        < Content-Length: 0
        < Location: https://www.garmin.com/en-US/?definedParams=123456789abcdefg
        < Cache-Control: max-age=0
        < Expires: Wed, 13 Sep 2017 04:24:58 GMT
        < Date: Wed, 13 Sep 2017 04:24:58 GMT
        < Connection: keep-alive
        < X-Robots-Tag: noindex
        < 
        * Connection #0 to host www.garmin.com left intact
        The response is a redirect (code 302). If you follow the redirect (by passing -L to curl), you'll get a response with an html body. This is not a huge surprise because the garmin website isn't likely to be hosting a web service at the given url; that is the address for the root of the company website.

        That said, I cannot reproduce a problem with the WebRequest sample on Linux Mint 17.3 with ConnectIQ 2.3.4. If I update the request in the example program to use the parameters from the docs and run it in the simulator, I see a response code -400 (Comm.INVALID_HTTP_BODY_IN_NETWORK_RESPONSE) which is exactly what I'd expect to see on a device or on windows.

        Travis

        Comment


        • #5
          I've verified the behavior with the ConnectIQ 2.3.4 SDK on Windows is the same as it is on Linux.. I get a -400 response code, both with the modified WebRequest sample code and with your source from github.

          Travis

          Comment


          • #6
            Hey,

            Travis is correct on the sample. It was meant to give a layout and complete a call. That call should produce a -400 response. We can try digging in a little more over here as well.

            Thanks,
            -Coleman

            Comment


            • #7
              OK, I've reworked it to hopefully make it easier to reproduce and
              to narrow the issue. Specifically it seems to be an https issue on
              Mac vs Windows (my two easy test boxes here).

              The updated sample is at https://github.com/abs0/GarminWebRequestTest
              and the fragment would be

              Code:
                 var url = "https://jsonplaceholder.typicode.com/posts/1";    
                 var params = null;    
                 var options = {    
                   :method => Communications.HTTP_REQUEST_METHOD_GET,    
                   :responseType => Communications.HTTP_RESPONSE_CONTENT_TYPE_JSON    
                 };    
                 var responseCallback = method(:onReceive);    
                 Communications.makeWebRequest(url, params, options, method(:onReceive));
              This fails for me on Mac 2.3.4 and runs fine on Windows. If I switch
              to http and bypass the "needs https" on the simulator it works on Mac

              Comment


              • #8
                Hey,

                I'm working through this right now and I'm getting the same thing on Windows and Mac. I'm getting a response 200 whether I use HTTPS requirements in the sim or not. Is there anything you can think that's unique to your setup on the mac?

                Thanks,
                -Coleman

                Comment


                • #9


                  Its a Mac mini running 10.11.6 with the stock Eclipse Oxygen downloaded in the last week or so. Originally I found the issue trying to perform the makeWebRequest part of an OAuth2 token exchange (code which was running fine on a Windows box), and a colleague tested it and saw the same issue on a Linux box which led me to suspect it was not just my machine. He's going to test with the latest GarminWebRequestTest to see if he's seeing the same issue on it.

                  The mac does seem to be running the Apple jdk1.8.0_91 which is not the latest, but hopefully not an issue

                  The OAuth2 using app is at https://github.com/TrainAsONE/trainasone-connectiq - you would need a clientid and secret to test which may be more effort than you want to take right now

                  Thanks

                  David
                  Last edited by SUSSAMB; 09-14-2017, 10:18 AM. Reason: Please try not to quote the post directly above yours, it's unnecessary and just clutters up the thread, thanks.

                  Comment


                  • #10
                    Hey David,

                    I've sent an email to request a Client Id and secret to the email listed in the github repo. I'd still like to try and reproduce what's going on. Something to note: I'm testing on a mac mini as well, but I'm running OS 10.12.6 with jdk 1.8.0_111. I'm not convinces that that would upend anything, but I suppose that could be a few variables to check.

                    Thanks,
                    -Coleman

                    Comment


                    • #11
                      Thanks Coleman,

                      My mini is the late 2009 model which maxes out at 10.11, but I'll take a look at switching Eclipse to using an external JVM, so I can at least be on the latest JDK.

                      (You should hopefully have a reply with a test client-id/secret for the trainasone-connectiq ap now

                      David

                      Comment


                      • #12
                        Upgrading java to 1.8.0_144 on the mini and rebuilding everything did not affect the situation (didn't expect it to, but it was an easy thing to test)

                        I should be able to borrow a MacBook Air tomorrow with 10.12 to see if it shoes the issue, or setup Eclipse on a Linux box (my default desktop is BSD and I use IntelliJ but I don't think I want to introduce that set of variables into this

                        Thanks

                        David

                        Comment


                        • #13
                          I've replied to you via email with my latest results in testing.

                          Thanks,
                          -Coleman

                          Comment

                          Working...
                          X