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...
Greg-DB
Dropbox Community Moderator
Dropbox Community ModeratorThe team has decided to update the API to allow some Content-Types such as "text/plain; charset=utf-8" on download endpoints. I'll follow up here once that is live.
That is really good news! Thank you for sharing, and I will give an update about it on my end as well!
- Greg-DBAPI v2 download endpoints now accept the following Content-Types:
- application/octet-stream
- text/plain
- text/plain; charset=utf-8
Hope this helps!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
I 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.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
