• State Verified Answer
  • Replies 10 replies
  • Subscribers 17 subscribers
  • Views 1533 views
  • Users 0 members are here
Options
Related

makeWebRequest with HTTP_RESPONSE_CONTENT_TYPE_AUDIO fails with UNSUPPORTED_CONTENT_TYPE_IN_RESPONSE

MichaelR
over 3 years ago

Hi there,

I just started experimenting with connect IQ and an audio provider. Unfortunately I can't get the webrequest to fetch me any audio file. It always fails with -1002 (UNSUPPORTED_CONTENT_TYPE_IN_RESPONSE) - in the simulator this is.

I am fumbling with this problem for days now, so I tried to start all over:

  1. Create a new audio provider Project - API-Level 3.2, Product: Fenix7
  2. Just add a simple request-function to the SyncDelegate.mc
  3. Call this function from onStartSync()
  4. Run the app in simulator, switch to "Sync" -> responseCode -> -1002
  5. The HTTP-Traffic monitor shows absolutely nothing. I also tried to see something in wireshark, but there is nothing either. It seems the request isn't firing at all.
  6. When changing the response-type to "json", I can see http-traffic in the monitor and wireshark, but of course I get the "invalid boby"-error 

The request-function has only a hard-code URL to an mp3-File stored on my personal nginx-server. I tried with and without "use https Requirements", no difference. 

Here is my request-function - could someone please hint me in right direction:

function downloadMedium() {

var options = {
:method => Communications.HTTP_REQUEST_METHOD_GET,
:responseType => Communications.HTTP_RESPONSE_CONTENT_TYPE_AUDIO,
:mediaEncoding => Media.ENCODING_MP3
};

Communications.makeWebRequest(
url,
null,
options,
method(:onMediumDownloaded)
);

}

function onMediumDownloaded(responseCode, data) {
System.println(responseCode);
}
Thanks for your help,
Michael
  • 0 over 3 years ago

    I came a small step forward. I tried an older SDK-Version and it worked with 4.0.6 - sort of...

    1. Using a non-secure http-connection seems to work, the mp3 gets downloaded.
    2. fun-fact: it worked wether I turned the "Device https Restrictions"-Option on or off - very strange!
    3. Changing to a secure connection and the download starts to fail again. This time I get responseCode = 0 UNKNOWN_ERROR
    4. In the HTTP-Traffic-Window I see 4 lines with non-readable content marked as "body", though it looks more like the ssl-handshake, because there are some readable url-fragments (http://crl.identrust.com/)
    5. never the less, I sideloaded the app onto my Fenix 7: I could start the sync but it seems it doesn't do anything and stays on the synching view, showing 0% and never finishes.

    This is driving me crazy, any help would be very much appreciated,

    Michael 

  • +1 over 3 years ago

    Ok, it's been a while since I messed with audio apps. In all honesty, I gave up on my app as I found the whole thing too unreliable with missing features to create the quality app that I wanted, but your message piqued my interest so thought I'd give things a go again. I'm amazed anyone outside of Garmin has been able to create working apps, but there are a few in the catalogue. Maybe things are better since I last tried, which I have to admit was years ago.

    Anyway, here is what I found.

    It appears that the 4.1.X SDKs are completely broken and it is impossible to download any audio content without getting a response code of -1002 (UNSUPPORTED_CONTENT_TYPE_IN_RESPONSE) and we do not even attempt to contact the server. Changing the responseType to something other than AUDIO, for example TEXT_PLAIN does cause the file to be downloaded and gives a response code of 200, but you do not get any audio in the library so this does not help.

    I do have better luck with older SDKs. If I go back to 4.0.X, for example, 4.0.10, I can get the download to work, but it will always fail with -1002 if I start the app in sync mode. If I switch to any other mode and then back to sync mode, the download works. Or if you exit the simulator and start it again, which resets the mode to playback, when I switch to sync mode, the sync works. I tried using your mp3 URL and that does work. But again, only when switching to sync mode from some other mode. If I start the app after exiting while in sync mode the initial sync fails with -1002. Of course, when the app is not running, you cannot change the mode and it remembers the last mode you were in when starting an app. Not sure why it works like that! It would make sense to me to be able to change the mode when an app is not running, so you can easily control what it will go to when you start the app.

    So, if you use 4.0.10 and make sure you always go to playback mode before exiting your app you may have better luck. Certainly, it works reliably for me with 4.0.10 if I do this.

  • 0 over 3 years ago in reply to gasteropod

    Just to follow up on this. It only affects the simulator. The code works, the download completes and gives a responseCode of 200 on a real device (I tried my EPIX) even when built with the latest 4.1.X SDK.

    I have reported the issue with the simulator to Garmin.

  • 0 over 3 years ago in reply to gasteropod

    Thanks gasteropod for your answer. I can confirm your analysis in most points:

    1. SDK 4.0.X works, 4.1.X doesn't -> no request is sent to the server
    2. I can also confirm your findings with the order of the media-modes -> no luck when starting in sync-mode
    3. And finally the request is working on my device (Fenix 7)

    What doesn't work for me is a secure connection with the simulator. That isn't to much a problem, since a non-secure connection is working so I can continue with my fiddling with the audio provider :) 

    For future reference:

    1. I initially had problems with the request on my device. Digging through some nginx-logs I could trace the problem to a SSL handshake error. It turned out, that my nginx installation had only a few ciphers whitelisted and couldn't agree with connect IQ
    2. The reason why my server doesn't work with the simulator through a secure connection is, that the simulator doesn't know the CA of my certificate (let's encrypt) - which is rather disappointing IMHO
      -> SSL_do_handshake() failed (SSL: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca:SSL alert number 48)

    Thanks for your help!

    Michael

  • 0 over 3 years ago in reply to MichaelR

    I'm using a secure connection in the simulator, and let's encrypt. Are you sure you have the entire certificate chain loaded in your server? I had problems until I did this. 

  • 0 over 3 years ago in reply to gasteropod

    Hmm, I have to admit that I don't no much about this ssl stuff. I just check my domain with some test-sites and they showed all green. Could you give me a hint where I could look what is missing? Thanks again.

  • 0 over 3 years ago in reply to MichaelR

    Yes, looks like you do have a complete chain:

    $ openssl s_client -showcerts -connect vizzini.spdns.org:443
CONNECTED(00000004)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = vizzini.spdns.org
verify return:1

    And I can download your MP3 file from my simulator over https so there is no fundamental problem.

    > the simulator doesn't know the CA of my certificate (let's encrypt)

    Is it possible that you do not have the root certificate installed on your PC? The simulator doesn't have it's own certificates and will use the PC certificates. The root CA is ISRG Root X1 and is loaded on mine. I cannot remember if I had to load that or if Windows did it for me. I suspect the latter. Do you get any security warnings if you go to https://valid-isrgrootx1.letsencrypt.org/ in your browser? This uses the same chain. If it's not loaded, you can download from https://letsencrypt.org/certificates/ and load onto your system. If / Once installed I would not expect you to get unknown CA errors.

  • 0 over 3 years ago in reply to gasteropod

    Thanks again for your help! FYI I use macos.

    1. The link with your test-site works 
    2. I checked the mentioned root ca in the systems keychain -> it is there
    3. I thought, maybe I have to add it to java somehow -> it was there as well in the cacerts-file
    4. I then tried a little SSL-Test-Program (https://matthewdavis111.com/java/poke-ssl-test-java-certs/) -> "connection successful"
    5. But still no luck with that damn simulator! :(

    It works with the non-secure connection - that is good enough to go on working on the audio app. I think I don't want to waste more time on this strange issue.

    And again: thanks for your afford and help - that is much appreciated.

    Michael 

  • 0 over 3 years ago in reply to MichaelR

    I did wonder if you could be on macos so tried not to assume anything. But I'm out of ideas now, could be a simulator bug I guess. Anyway, I'm out of ideas, and you have a workaround, so good luck.

    It's got me back into playing with audio apps again and I've already found a couple of other issues. Stick with the deprecated Media.notifySync* functions. The Communication versions don't work on Epix2! 

  • 0 over 3 years ago in reply to gasteropod

    Yes, the Media.notifySync*-Bug is also present on my Fenix 7. Thanks for the hint!

    The last days I prepared my server (Raspi) to play nice with the audio provider. This https-paradigm is really annoying when you only want to work in a local network. If we sync an audio file with https it is routed through the routers gateway into the internet and then back to the local network again. That's a no-go with my 12 mbits upstream and an 1gig audiobook.

    My solution: set up a local DNS-server and rebind the secure domain directly to the local IP. Feels a little like overkill for a simple file-transfer, though.

    I hope to start with same functions for the app tonight :)

    CU

    Michael