Error in call to API function "files/upload": Bad HTTP "Content-Type"

[vijaysingh109]

Hi,

We are trying the upload a file from ZOHO deluge to dropbox upload API and getting the following error.

Error in call to API function "files/upload": Bad HTTP "Content-Type" header: "application/octet-stream; boundary=e4_HWM6hUnWSMO0XyNdrs9osravFMTxunGA". Expecting one of "application/octet-stream", "text/plain; charset=dropbox-cors-hack".

How do I fix it?

[Greg-DB]

The Dropbox API /2/files/upload endpoint expects the HTTP request's "Content-Type" header to be  "application/octet-stream" or "text/plain; charset=dropbox-cors-hack". This error is indicating that your app is instead supplying "application/octet-stream; boundary=e4_HWM6hUnWSMO0XyNdrs9osravFMTxunGA".

That extra "boundary" portion is typically used with "multipart" requests, which the Dropbox API doesn't expect or support. You'll need to configure your HTTPS client to not send this kind of request. Your HTTPS client isn't made by Dropbox though, so I can't offer much help with that. You may want to refer to the documentation for your network client for information on how to configure this.

[vijaysingh109]

Hi Greg.

Thanks for the reply, We are not setting any additional header except "application/octet-stream".

Here is what we are setting the headers:

mapOfHedder.put("Content-Type","application/octet-stream");

Is there any other thing which you can think of the reason for the specific error?

Unable to attach snapshot from select file else I could have done it.

[Greg-DB]

I see that you are setting a correct value in your code, but it looks like your network client is overriding that setting for some reason. We have seen that sometimes, e.g., where the network client later interprets something else, for instance the way the request body itself is being set, and then overwrites the Content-Type value. 

You'll need to investigate why your network client is overriding your value, and how to prevent that. That will be specific to your client though, so I can't provide specific instructons unfortunately.

[Ronaldo77]

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);

[Greg-DB]

@Ronaldo77 That line of code would disable verification of the SSL/TLS certificate, which should not be relevant to the original discussion here. In any case, we do not recommend disabling the SSL/TLS certificate verification, as a matter of security.

[Nilpohc]

Hi,

The problem here is the multipart thing, which is triggered in PHP/CURL when you set CURLOPT_POSTFIELD to an array. You need to send the file in the "old" way, which means setting the CURLOPT_POSTFIELD to a special string with the "@" prefix followed by the full (real) path to the file you want to send.

Unfortunately, it doesn't seem to work anymore, since it's deprecated in favor of the "new" way (as of PHP 7) which is to use the CURFile class (or the curl_file_create() function)...which ends up with an array and you're back to square one 😕

The workaround is to not use CURL, but instead file_get_contents() along with a stream_context.