Dropbox API v2 for Second Life

[SephDragoon]

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.

[SephDragoon]

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.

[OzLinden]

I suggest retrying your POST test with an

Accept: text/plain

header

[SephDragoon]

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.

[SephDragoon]

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.

[OzLinden]

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...

[SephDragoon]

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!

[SephDragoon]

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.