You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
SW updates via OTA dropbox failes CC3200
Hi,
Last week, I think about thursday 21st of October OTA updates started to fail. They have been working for years. I have turned the OTA logs on from the application side and you can see thes...
Wonderful, OTA tested and working. Thanks a lot for fast and efficient solution to our problem
Greg-DB
Dropbox Staff
Dropbox StaffIt looks like your client is getting a 400, but I just gave that a link a try and it is working for me. Can you print out the full request and response, including both headers and bodies, to see what might be going on there?
Hi Greg,
The problem was identified from TI.
It is due to the "#" that appears now in the received Dropbox URL (in the response of the "/2/files/get_temporary_link" API) .
I have got a fix in the code so I will inplement this in it.
I have a problem though that the devices in the field cannot be updated due to this so is there any possibility from your side to remove the "#" in the URL provided in the "/2/files/get_temporary_link" response.
BR
Ingibergur
- Greg-DB
Thanks for following up. I see you're referring to the links returned by the /2/files/get_temporary_link endpoint. Per the Dropbox API spec, the returned
GetTemporaryLinkResult.linkfield is only documented asStringwithout a more specific format/domain guaranteed. The exact link format/domain used may vary over time as the Dropbox implementation is updated and maintained, but the link returned should always be valid for four hours.The implementation for that endpoint has been recently updated, for instance, to return links with a different domain and format, but the returned links are still valid. Specifically, the new format contains a "#" at the end of the link. Per the HTTP spec, the "#" is a reserved character for identifying the beginning of the "fragment" portion in a URI.
One thing we're seeing, however, is that some HTTPS client handle the "#" in the URL incorrectly. HTTPS clients are not supposed to include that portion in requests to the server, but some clients mistakenly do. If that is the issue, you can work around this by removing that trailing "#" from the end of the link before passing it to your client. (Be sure to do so in a fail-safe manner though; the Dropbox API spec does not guarantee its presence, so make sure your code wouldn't fail if it isn't present to begin with.)
I understand you are not able to deploy such an update however, because this is the mechanism you would use to do so anyway. That being the case, I'm raising this with engineering to see if we can accommodate this somehow on our side, though I can't make any promises right now. I'll follow up here with any updates on that.
Hi Greg,
Thanks for following this up. As you state I cannot update devices in the field, so I hope you can do something for me.
BR
IngiHi,
We are in the same boat. I thought this was part of the scoped apps so I changed the app to a scoped app. This generated a new access token. This is bad for us. We have thousands of devices in the field that cannot be downloaded with the newly generated access token. Is it possible to set the access token to the token they already have? Additionally the modified character set is a problem for us too. Thank you for looking in to this.
Vic
About Discuss Dropbox Developer & API
Make connections with other developers
