We Want to Hear From You! What Do You Want to See on the Community? Tell us here!
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 detailed more of this in my latest post.
Hello. I have happily been a user of yours for last several years, using the Dropbox API from within Second Life. This has given me a rather powerful tool for handling data storage, but your v2 API will not function from withint Second Life any long.
I have been trying to migrate from v1 to v2 ahead of time, and I ran into an error that cannot be fixed within Second Life.
Error in call to API function "files/download": You provided a non-empty HTTP "Content-Type" header ("text/plain; charset=utf-8"). This API function requires that the header be missing or empty.
The problem lies here in Second Life:
http://wiki.secondlife.com/wiki/LlHTTPRequest
You cannot override the Content-Type headed, because it is automatically generated from within Second Life itself. Can you fix this problem? There seems to be little reason that the API could not ignore this content type header if you are doing a download, like it did before.
This prevents me from upgrading to v2, and would break all of my current code in Second Life if it cannot be fixed.
29 Replies
- Greg-DB
Dropbox Community Moderator
Dropbox API v2 does expect the Content-Type to match the type of the content in the body, and in the case of content-download endpoints, this should accordingly be missing or empty, as there is no content in the body.
Are you perhaps able to explicitly specify the empty string "" using "HTTP_MIMETYPE" as mentioned in the documentation you linked to?
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-DBThanks 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!
Oh, I forgot to let you know.... I'm the Director of Second Life Engineering, and one of the contributors to the HTTP 1.1 specifications at the IETF.
So, is there ever going to be anything done about this? We're coming up on the date when v1 can no longer be used, and I have NO solution to this. Anyone?
- Greg-DBI don't have an update on this on our side unfortunately. I'll check in with the team, and follow up here if/when I have any news.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
