HEADS UP: Server.downloadFile() issue on macOS Sequoia - and a solution
-
The p part is the authorization that’s getting passed to the server. I was having an issue using that with GET - again, very inconsistent and on some systems only, and I can’t reproduce it on any fo the 3 macs I have around - as though the parameter was not being passed to the server properly. So maybe it’s about that, but then I have no clue on how to troubleshoot this further.
-
@tomekslesicki Nothing in particular stands out to me. Here's my downloader if you want to compare.
-
Is there any way to print the final url with the parameter part? The docs https://docs.hise.dev/scripting/scripting-api/server/index.html#callwithget say that "The parameters have to be a non-nested JSON object and will automatically change the URL to embed these parameters". What does the final url look like after the change?
-
@tomekslesicki said in HEADS UP: Server.downloadFile() issue on macOS Sequoia - and a solution:
The issue was only present on macOS Sequoia,
Have the three customers tested other versions of MacOS?
-
@d-healey of course not ;-) But I also have one guy on Windows experiencing this now.
-
@tomekslesicki said in HEADS UP: Server.downloadFile() issue on macOS Sequoia - and a solution:
of course not ;-) But I also have one guy on Windows experiencing this now.
What is the common link between all the people who have the issue?
-
@d-healey none, but I suspect the problem is with the parameter part of the url called by HISE. The reason I suspect this is that the POST calls are made to a different server, and they work fine. The download callback works fine wherever I test it and - again, works for the vast majority of users - but I guess it's possible that the parameter part is not attached to the call properly, and the server rejects it because it doesn't pass the authorization.
-
@tomekslesicki said in HEADS UP: Server.downloadFile() issue on macOS Sequoia - and a solution:
I suspect the problem is with the parameter part of the url called by HISE.
If that was the case wouldn't it fail for all users?
-
@d-healey maybe it works on some systems but not others, for whatever reason? Is there a way to get the final url of the call affected by the parameter property?
-
@tomekslesicki said in HEADS UP: Server.downloadFile() issue on macOS Sequoia - and a solution:
maybe it works on some systems but not others, for whatever reason?
That's why we need to find the common factor. Then you can recreate the system in a VM and debug it.
What OS are they using?
What DAW are they using?
Are you able to make a standalone app that just does the download call so that it can be tested in isolation?
Do they have a firewall?
Do they use a VPN?
Who is their internet provider?
What country are they in?
etc.Find out everything that they have in common and build a VM to match.
@tomekslesicki said in HEADS UP: Server.downloadFile() issue on macOS Sequoia - and a solution:
Is there a way to get the final url of the call affected by the parameter property?
Only on your server I think.
