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
Dropbox API v2 for Second Life
Update (01/14/2019): Finally back to trying to use this code. A resolution was seemingly made, but not fully implemented. I am able to access the API now, but I still cannot use file/download. I have...
It cannot accept an empty string sadly. I can attempt to get them to add that functionality, but I do not know how long that will take. I would still like to pursue both options, since either solution, accepting an empty string or ignoring the MIME type when it is expected to be empty.
This is the exact error returned when I try it:
[06:06:37 PM] AoW:Reloaded HUD (v0.0.6a) - v2 API Example: Unsupported or unknown Content-Type.
- Greg-DB
Dropbox Staff
Thanks for trying that out. I can't make any promises, but I'll send this along to the team as a request to allow this on our side.Alright. Thank you so much for working with me. Hopefully it is all handled before v1 goes away.
- We are investigating whether or not we can, in a backward-compatible way, make a change to how Second Life sends requests like these, but I would respectfully suggest that the check your API is enforcing does not add value and is not appropriate.
HTTP defines a few different ways for the recipient of a request to determine whether or not there is content in the request body, including Content-Length and Transfer-Encoding. If Content-Type is not a multipart type (which it is not in this case), then one of those other mechanisms is required to determine the size of the body and the type specifies only how it should be interpreted. It is quite possible that some end users (possibly including ours - we have not investigated yet) will find that a proxy somewhere in the path will have added a Content-Type header even though there is no content; nothing in the HTTP specifications prohibits this, just as nothing in the specs requires that you reject a request that has a header that isn't needed to interpret the request.
You've added a check that makes your API incompatible without actually serving any useful purpose; I suggest that you allow and ignore the header if there is no content in the request.- Greg-DBThanks for the feedback!
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
