Child Item

Error 400 when trying to download a file

Hello,

I'm using Dropbox for OTA. It worked for long time up until couple of weeks ago. Now, connection is established, folder list is downloaded, but when trying to download a file, I'm receiving Error 400. Your support team answered similar questions (around Error 400), claiming that the format of the HTTPT request might not be 100% correct.

This is an embedded system and I'm using a library of the chip vendor, Texas Instrument (TI), so I do not have access to exact format of the HTTP request. I spoke with TI and they asked for a log from your server that shows the mismatch.

Is there a way to get a log from your server that shows the format of the received HTTP request?

For a reference, here is the Dropbox HTTP Response:

<!DOCTYPE html><LF>
<html><LF>
<head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><LF>
<meta name="viewport" content="width=device-width, initial-scale=1" /><LF>
<title>Dropbox - 400</title><LF>
<link href="">cfl.dropboxstatic.com/.../error.css" rel="stylesheet" type="text/css"/><LF>
<link rel="shortcut icon" href="">cfl.dropboxstatic.com/.../><LF>
</head><LF>
<body><LF>
<div class="figure"><LF>
<img src="">assets.dropbox.com/.../target-miss.svg" alt="Error: 400"/><LF>
</div><LF>
<div id="errorbox"><LF>
<h1>Error (400)</h1>Something went wrong. Don't worry, your files are still safe and the Dropbox team has been notified. Check out our <a href="">status.dropbox.com">Status Page</a> to see if there is a known incident, our <a href="">www.dropbox.com/help">Help Center</a> and <a href="">forums.dropbox.com">forums</a> for help, or head back to <a href="">www.dropbox.com/.../a>.<LF>
</div><LF>
<LF>
</body><LF>
</html><LF>

Thanks,

Shimon

Find more posts tagged with

API

Abuse

Comments

Greg-DB

Dropbox doesn't offer a way to retrieve request/error logs like that, but I'll pass this along as a feature request. I can't promise if or when that might be implemented though.

A 400 error like that would indicate an issue with how the request was formatted, and in cases like that we recommend using client-side logging to inspect the requests that the client is making. You may want to refer to the documentation for the network client you're using and see if you can enable some client-side logging and use that to inspect the request when you reproduce the error.

Здравко

@sz3324 wrote:
...
Is there a way to get a log from your server that shows the format of the received HTTP request?
...

Hi @sz3324,

Dropbox (and most other similar services) doesn't provide such logs usually, so server side logs gonna be unavailable to you, as Greg said. In addition, on embedded systems, client side logs are relatively limited where available at all. Usually some coding equilibristics are needed to redirect log to external logging server in such cases, cosa limited local resources.

In spite, there's an easy trick that let you evaluate the transaction without significant effort and as accurate as possible. Just trace the HTTP of interest itself. 😉 An easy way is using pseudo server as denoted here. Make needed temporary changes to the troublesome request (the download - in your case). In addition you may use some helper tool - like Wireshark, for instance.

Hope this helps.

sz3324

Thanks. I'll try a pseudo server

sz3324

Hello,

Here is the problematic request (the one acknowledged with error 400), captured locally just before submitted:

'list_folder' request:
POST /2/files/list_folder HTTP/1.1<CR><LF>
Content-Type: application/json<CR><LF>
Authorization: Bearer sl.Bwg31qNyvs2KjuANe6wfTrBJu2LBO7mrVltkFc9dSYg9VCVfg4NhKyPbZ4Es5QSy2BMHTlno5OBgiF14RAOtFCHpbyWuJ1T-EY5jxgKIbOhDv1Wrq4DwXJR6SUHabSP4AdAHwTM<CR><LF>
Host: api.dropboxapi.com<CR><LF>
Content-Length: 41<CR><LF>
<CR><LF>
{"path": "/ota_bundle_office","limit": 1}<CR><LF>

'list_folder' response:
{"entries": [{".tag": "file", "name": "20240221072512_CC3220SF.tar", "path_lower": "/ota_bundle_office/20240221072512_cc3220sf.tar", "path_display": "/ota_bundle_office/20240221072512_CC3220SF.tar", "id": "id:dIosUmeVHMoAAAAAAAABVA", "client_modified": "2024-02-21T05:31:31Z", "server_modified": "2024-02-21T05:31:31Z", "rev": "01611dda3b09665000000026de23b50", "size": 573440, "is_downloadable": true, "content_hash": "c31073c7b9ea0a3fa69ff61a6ab8d80e5b51d9fa4ef8eee49384cc5b64071406"}], "cursor": "AAGUl6koiJNa5jclgopptYqRLLcfflMtyH4JCF0vnMrlWQ51eowHqMHoXjqHlaDMXOrhfzWY3yBqNRuGqrAgeS2n-Yf9OlPbeL03QBJ9uw3s2sAm-dAMk9r5JiK8ypWoLwhrYUtVsesIJ_8wu9N1J00J_kZpWsHG1iiuws4AmBtggVPtTKBNtD8TIZMGwQ9z1RrZtbYuHmoMXZ_Vm8a8CRDYen9zNkZsMRHsMOCUkj0b9w", "has_more": false}0<LF><CR>

problematic request:
POST /2/files/get_temporary_link HTTP/1.1<CR><LF>
Content-Type: application/json<CR><LF>
Authorization: Bearer sl.Bwg31qNyvs2KjuANe6wfTrBJu2LBO7mrVltkFc9dSYg9VCVfg4NhKyPbZ4Es5QSy2BMHTlno5OBgiF14RAOtFCHpbyWuJ1T-EY5jxgKIbOhDv1Wrq4DwXJR6SUHabSP4AdAHwTM<CR><LF>
Host: api.dropboxapi.com<CR><LF>
Content-Length: 58<CR><LF>
<CR><LF>
{"path": "/ota_bundle_office/20240221072512_CC3220SF.tar"}<CR><LF>

error 400 response:
<!DOCTYPE html><LF>
<html><LF>
<head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><LF>
<meta name="viewport" content="width=device-width, initial-scale=1" /><LF>
<title>Dropbox - 400</title><LF>
<link href="https://cfl.dropboxstatic.com/static/metaserver/static/css/error.css" rel="stylesheet" type="text/css"/><LF>
<link rel="shortcut icon" href="https://cfl.dropboxstatic.com/static/images/favicon.ico"/><LF>
</head><LF>
<body><LF>
<div class="figure"><LF>
<img src="https://assets.dropbox.com/www/en-us/illustrations/spot/target-miss.svg" alt="Error: 400"/><LF>
</div><LF>
<div id="errorbox"><LF>
<h1>Error (400)</h1>Something went wrong. Don't worry, your files are still safe and the Dropbox team has been notified. Check out our <a href="https://status.dropbox.com">Status Page</a> to see if there is a known incident, our <a href="https://www.dropbox.com/help">Help Center</a> and <a href="https://forums.dropbox.com">forums</a> for help, or head back to <a href="https://www.dropbox.com/home">home</a>.<LF>
</div><LF>
<LF>
</body><LF>
</html><LF>
<LF><CR>

Can you please help identify the incompatible format part? Thanks

Здравко

Hm..🤔 In general everything seems fine and no error should be expected. There is one exception though - one more symbol:

@sz3324 wrote:
..., "has_more": false}0<LF><CR>
...

The zero here is definitely not on place! If this is not some copy/paste mistake, you may have some trouble in your system that you have to debug. In all cases, you may print responses headers out and post here 'x-dropbox-request-id' header. This will let additional error tracing.

@sz3324 wrote:
...
Can you please help identify the incompatible format part? Thanks

The path's format is all right. There should be something "behind the scene" though, as I said. By the way to see everything follow my directions exactly - the output, you posted, does NOT come from pseudo server since incomplete!

Good luck.

Greg-DB

@sz3324 As Здравко said, the request appears correct. I tried replicating the request as shown here and it did not fail like that for me, so please check that that's exactly what you're actually sending.

sz3324

Here is a capture of the request when redirected to AWS (API Gateway service). It looks perfectly correct:

(bdc789db-0418-470d-8cd0-c875d80b44b3) Method request headers: {Authorization=*******************************************************************************************************************************************CLnyJw, X-Forwarded-Proto=https, X-Forwarded-For=2.53.174.13, Host=d13k3bi9ke.execute-api.us-east-1.amazonaws.com, X-Forwarded-Port=443, X-Amzn-Trace-Id=Root=1-65e41272-37ecaf0e7538265a0082a13f, Content-Type=application/json}

(bdc789db-0418-470d-8cd0-c875d80b44b3) Method request body before transformations: {
"path": "/ota_bundle_office/20240221072512_CC3220SF.tar"
}

Adding the fact that the request is perfectly decoded by other servers (I tried AWS and httpdump.app) to the fact that it worked perfectly with Dropbox.com up until couple of weeks ago, might show that a recent change that you made in your server is the root cause for this issue. I do not think that this is a format issue. Please advise. Thanks

Greg-DB

That doesn't seem to be the raw request, and regardless it's not the request to the Dropbox servers directly, so unfortunately we can't use that to debug this.

Whatever the issue is, we'll need to be able to reproduce the issue to confirm what is going wrong and how to fix it. I replicated the request you shared earlier, but that did not reproduce the issue, so it does not seem that that is a correct representation of the request being made. It's important to make sure we're investigating the exact right requests; sometimes substituting in different servers can be misleading as different servers may support different protocols/versions/features. For example, different servers may support different versions of the HTTP protocol, like how the api.dropboxapi.com servers support both HTTP/1.1 and HTTP/2, and will prefer HTTP/2 when possible.

Have you been able to reproduce the issue outside of that particular embedded system? Please let us know how to reproduce the issue, e.g., using curl, so we can investigate.

Another thing to note is to make sure that the client is sending the exact full amount of data as specified in the 'Content-Length' request header. If the client doesn't send that amount of data, the server can respond with that error.

sz3324

As I wrote above, this is an embedded system and I'm using a library of the chip vendor, Texas Instrument (TI). Hence, I do not have access to exact format of the HTTP request.

I can only direct the request to another server (as I did with AWS and httpdump.app) or ask you for a log from your server that shows the mismatch, which then I can share with TI and ask them to fix.

Greg-DB

Dropbox doesn't offer request logs like that, so unfortunately I can't provide a copy of the request that the client made. That kind of inspection would need to be done client-side.

Greg-DB

@sz3324 I just wanted to follow up here to let you know we believe we've tracked down and replicated the issue here. Please refer to the post here for more information.