We’re Still Here to Help (Even Over the Holidays!) - find out more 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...
Hello. I have finally come back to the platform on another attempt to use the endpoints. Picking up where I left off, I decided to finally try and see if it would work, but upon trying it out, I got the same error as before. I am specifying the MIME type as both "text/plain" and "text/plain; charset=utf-8". Neither one shows any different result.
So far it is spitting back "Unsupported or unknown Content-Type." once again. Maybe something else has change since my original attempt, but are the new supported content types still working, or was something eventually changed?
Edit: Alright, I have finally been able to confirm that the error stems only from file/download. Other API calls seem to be working, but I am unable to get the contents of the .txt files I had on the server previously. The content type is still incorrect when I am receiving a response from the server.
http://wiki.secondlife.com/wiki/Http_response
Status 415 "Unsupported or unknown Content-Type"
The remote server did reply to your request but the Content-Type of the reply (such as XML, JSON, Atom, RSS, PLS) is not recognized by the LL server and so is not passed back to the script. You can assume that 415 means the server heard your request and did reply.
Greg-DB
Dropbox Community Moderator
Dropbox Community ModeratorI just tried this, and the new supported content types are working for me. Here are a few sample calls:
$ curl -X POST https://content.dropboxapi.com/2/files/download \
> --header "Authorization: Bearer <ACCESS_TOKEN>" \
> --header "Dropbox-API-Arg: {\"path\": \"/test.txt\"}"
This is the test file data.
$ curl -X POST https://content.dropboxapi.com/2/files/download \
> --header "Authorization: Bearer <ACCESS_TOKEN>" \
> --header "Dropbox-API-Arg: {\"path\": \"/test.txt\"}" \
> --header ""
This is the test file data.
$ curl -X POST https://content.dropboxapi.com/2/files/download \
> --header "Authorization: Bearer <ACCESS_TOKEN>" \
> --header "Dropbox-API-Arg: {\"path\": \"/test.txt\"}" \
> --header "Content-Type: application/octet-stream"
This is the test file data.
$ curl -X POST https://content.dropboxapi.com/2/files/download \
> --header "Authorization: Bearer <ACCESS_TOKEN>" \
> --header "Dropbox-API-Arg: {\"path\": \"/test.txt\"}" \
> --header "Content-Type: text/plain"
This is the test file data.
$ # using the verbose option for more detail:
$ curl -vX POST https://content.dropboxapi.com/2/files/download \
> --header "Authorization: Bearer <ACCESS_TOKEN>" \
> --header "Dropbox-API-Arg: {\"path\": \"/test.txt\"}" \
> --header "Content-Type: text/plain; charset=utf-8"
> POST /2/files/download HTTP/1.1
> Host: content.dropboxapi.com
> User-Agent: curl/7.54.0
> Accept: */*
> Authorization: Bearer <ACCESS_TOKEN>
> Dropbox-API-Arg: {"path": "/test.txt"}
> Content-Type: text/plain; charset=utf-8
>
< HTTP/1.1 200 OK
< Server: nginx
< Date: Tue, 15 Jan 2019 16:25:48 GMT
< Content-Type: application/octet-stream
< Content-Length: 27
< Connection: keep-alive
< accept-ranges: bytes
< etag: W/"73c1c021eccc7"
< pragma: no-cache
< cache-control: no-cache
< original-content-length: 27
< dropbox-api-result: {"name": "test.txt", "path_lower": "/test.txt", "path_display": "/test.txt", "id": "id:25N5ksooX-sAAAAAAAKn0Q", "client_modified": "2019-01-15T16:24:48Z", "server_modified": "2019-01-15T16:24:49Z", "rev": "73c1c021eccc7", "size": 27, "content_hash": "cceac37da5288a6b6716737310c14305c9b16a6e0ff0abce4a306c3de3a59f75"}
< X-Server-Response-Time: 1984
< X-Dropbox-Request-Id: c87ab76814c43ef58c5d284e646fdec7
< X-Robots-Tag: noindex, nofollow, noimageindex
<
* Connection #0 to host content.dropboxapi.com left intact
This is the test file data.
While you can now specify any of those three newly supported Content-Type values (or none) for the request, the response's Content-Type for /2/files/download is not guaranteed to be the same as that of the request; it is always "application/octet-stream" to indicate that it is returning the binary data for the requested file (assuming the call succeeded).
I'm not familiar with your platform, but from the SecondLife documentation you quoted it sounds like the issue now is that "LL server" isn't accepting the the "application/octet-stream" response Content-Type for the response from Dropbox for the /2/files/download call.
- I know how to get the calls to function. The platform is still fairly straight forward. You can say that Linden Labs is at fault for their specifications, yes. However that is the easy way out ignoring that if version 1 of the API was not depracated, this would still be functioning. I wrote this system in v1, and there was no guarantee that it would continue to work, but right now the point remains that the differences between v1 and v2 have broken code for some people to a point where it could not continue after version 1 was deprecated. I had to abandon my project a year and a half ago, and after being told it would work I came back to it. Only, it doesn't work.
- Greg-DB
Thanks for the feedback! It's much appreciated, and I've shared it with the team.
As far as specific changes to API v2 are concerned, the original requested change here, to support more Content-Type values for requests to /2/files/download, was implemented and is working. Is there another specific change that would be helpful for API v2? I can't make any promises as to whether or not we'd be able to make any particular change, but I'd be happy to send along another request to do so.
- Well, the request being accepted in other content types only does any good if the response does the same thing. Right now the request is working, but I cannot receive the response since its content type is fixed. One does little good without the other.
I suggest retrying your POST test with an
Accept: text/plain
header
- That I will try as soon as I get home, thank you.
- Greg-DB
I recommend looking into getting the LL server updated to accept the "application/octet-stream" Content-Type, as it looks like that's where the current rejection is taking place.
I'll be happy to pass along a request to change something on the Dropbox side too, but I should reiterate I can't guarantee such a change would be implemented. Can you specify exactly what change(s) would be necessary though?
Also, I just checked and unfortunately specifying an "Accept" request header like OzLinden suggested won't change the result in this case.
- Well, there goes that. If some solution like what he suggested could be made though, it would help. Otherwise a way to get plain text responses would be lovely. I can understand if that won't work for most file types, but plain .txt files shouldn't be a problem.
- Greg-DB
Ok, thanks! I've sent that feature request along. I'll follow up here with any updates on that, but at the moment I'm not aware of any such planned update.
I'm afraid that there's no way for us to modify Second Life to allow anything but a text-based content type.
I'm not clear on how to test the Dropbox API... is it true that if I upload something as text/plain I can only get it back as application/octet-stream? That doesn't seem very useful...
- It works very well for what it is. It had been my go to method of data storage from second life for a long time. The main advantage is that unlike a php to sql method, you do not need to use an intermediary server. The downside is that all logic then has to be put into the LSL script. I may have found a method to make it work for now, but it is a hack using the get_temporary_link call.
- Greg-DB
OzLinden If you want to test the Dropbox API, I have a few examples in this comment from earlier in the thread that show use of the /2/files/download endpoint. The API v2 Explorer can be useful for testing/prototyping calls like this.
In any case, the /2/files/download endpoint does return "application/octet-stream" as the response's Content-Type for any type of file.
SephDragoon I'm glad to hear you may have found a workaround!
- I would not consider it a solution, but I am able to get the data back out. Since upload works as is, I can still use drop box, but I will be relying less heavily on it. A two step process for every data lookup isn't ideal.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
