Need to see if your shared folder is taking up space on your dropbox 👨💻? Find out how to check here.
Forum Discussion
Solved
Error 400 when trying to access file using "WinHttp.WinHttpRequest.5.1"
Hello, i am doing simple download utility for my clients. I am using Autohotkey. The issue is that since 17.8.2021 the clients started to report that its not downloading from their dropbox anymore....
I found the reason and the solution.....
the last redirect location was:
https://uc6f15ff258e57f8afd9c4e5d97e.dl.dropboxusercontent.com/cd/0/get/BU0a9_vyDu1w8UAsQg0cnf9-yTQJDMCU4EqgojJU4cwU55xwOuPI3X7ljfhNtG1JGjRLDOj68jVzvOlOSD0HGhc85WJkq68qklFGmDWXgTVcgbaL51PSrNoui2R-b5Hmd-ds2DioeAkw7fxQo4ajtp-X/file?dl=1#
And for some reason the WinHttp.WinHttpRequest.5.1 have issue with the # at the end of the link. So I assume, that that is the change which Dropbox did in last 2 weeks.
For this reason i cannot use build in redirects inside the WinHttp.WinHttpRequest.5.1 object. And i need to redirect by the script.
winHttp.Option(6) = false
And then just remove the # from the link which i retrieve from location.
Which means that https://uc6f15ff258e57f8afd9c4e5d97e.dl.dropboxusercontent.com/cd/0/get/BU0a9_vyDu1w8UAsQg0cnf9-yTQJDMCU4EqgojJU4cwU55xwOuPI3X7ljfhNtG1JGjRLDOj68jVzvOlOSD0HGhc85WJkq68qklFGmDWXgTVcgbaL51PSrNoui2R-b5Hmd-ds2DioeAkw7fxQo4ajtp-X/file?dl=1was working.
So its resolved.Anyway it would be great if your server would not add the # to the location.
Curl was working and it helped me to find out that it also removed the # from the link.
Thank you for support.
Thank you. Yes the issue is still there.
You are right i am not using api as by the nature of the software which i am doing, its not possible to do as api.
I also do not expect that you would give support of Autohotkey.
And to use curl instead of com Object with Http.. is not an option for me. As you can see i followed the redirects as well but still got the 400 response.
I understand that curl is doing the job fine as well as any web browser.
I am wondering if there is any way which would tell me why i get the e400 from your server based on the requests which i posted.
And please understand that i was downloading from the Dropbox this way more then a year and suddenly it started to throw 400 a week ago.
It would maybe help to know, what was changed, or what is expected to be included inside the request so that it works again.
Greg-DB
Dropbox Community Moderator
Dropbox Community ModeratorFirst, for reference, the Dropbox API does offer the ability to retrieve file data from a shared link (without using the "dl=1" option on the link itself), via the /2/sharing/get_shared_link_file endpoint. You may want to look into whether or not that suits your use case.
Anyway, I don't know off hand what may have changed here, but I'll try to help however I can. Is the output you shared here the most verbose output you can get from your client? Unfortunately it doesn't offer anything I can use to track this down specifically. For instance, the final failing response doesn't contain a 'X-Dropbox-Request-Id' (though that may not be useful even if it were included since it's not an actual API request anyway).
In any case, I tried replicating the final call manually using curl, by sending the specific headers like shown in your output, but the request still worked. Are you able to manually reproduce this using curl by any chance? It would serve as a useful reference if you can, just for the sake of troubleshooting.
OK. Its a good point. I will try to use curl for testing purposes for this case.
From previous tests with comObject i saved the complete response including the html which dropbox returned.
https://brain.industries/data/response.txtThere is really nothing more coming back.
It would be really nice if dropbox would respond with the reason of error.- Greg-DB
Thanks. Yes, unfortunately there isn't really anything else here that would be useful. Let me know if you can reproduce this with curl directly though.
I found the reason and the solution.....
the last redirect location was:
https://uc6f15ff258e57f8afd9c4e5d97e.dl.dropboxusercontent.com/cd/0/get/BU0a9_vyDu1w8UAsQg0cnf9-yTQJDMCU4EqgojJU4cwU55xwOuPI3X7ljfhNtG1JGjRLDOj68jVzvOlOSD0HGhc85WJkq68qklFGmDWXgTVcgbaL51PSrNoui2R-b5Hmd-ds2DioeAkw7fxQo4ajtp-X/file?dl=1#
And for some reason the WinHttp.WinHttpRequest.5.1 have issue with the # at the end of the link. So I assume, that that is the change which Dropbox did in last 2 weeks.
For this reason i cannot use build in redirects inside the WinHttp.WinHttpRequest.5.1 object. And i need to redirect by the script.
winHttp.Option(6) = false
And then just remove the # from the link which i retrieve from location.
Which means that https://uc6f15ff258e57f8afd9c4e5d97e.dl.dropboxusercontent.com/cd/0/get/BU0a9_vyDu1w8UAsQg0cnf9-yTQJDMCU4EqgojJU4cwU55xwOuPI3X7ljfhNtG1JGjRLDOj68jVzvOlOSD0HGhc85WJkq68qklFGmDWXgTVcgbaL51PSrNoui2R-b5Hmd-ds2DioeAkw7fxQo4ajtp-X/file?dl=1was working.
So its resolved.Anyway it would be great if your server would not add the # to the location.
Curl was working and it helped me to find out that it also removed the # from the link.
Thank you for support.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
