Dropbox API v2 for Second Life

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.