cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Share your feedback on the Document Scanning Experience in the Dropbox App right here.

Dropbox API Support & Feedback

Find help with the Dropbox API from other developers.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

400 status code for a regular GET request

400 status code for a regular GET request

MikkBenelis
Helpful | Level 5

Seems like I'm facing the same or really similar issue. Just wanted to try Dropbox for my pet-project read-only data storage and found that it always responds with a 400 status code for a regular GET request.

 

For testing purposes I created a text file with the "Hello world!" string and tried to get it using the shared link. It worked in browser without any issues. It worked in Postman and I found that the "Host" header is required. But it does not work with the HTTP request library I'm using in my project. I can't control its under-the-hood behavior and as a result getting constant 400 response.

 

Some details: I'm using an open-source Godot Engine with its high-level HTTPRequest class to send these requests. Not sure what library is behind this class, but most probably it is something that can be used by other companies as well...

1 Accepted Solution

Accepted Solutions

MikkBenelis
Helpful | Level 5

Hi @Здравко@Greg-DB and sorry for the late response. Today I finally managed to understand the root cause of the issue and found a workaround to it. It is not related to the extra new line I thought earlier, but it is something with the redirect URL received after the first GET request. I was a bit confused by the automatic redirects everywhere so the actual error was tied to the second request. Below are my test scenario, issue description and a workaround.

 

Test scenario:

1. Send a GET request to this URL: https://www.dropbox.com/scl/fi/fc5rwkff82yvy66ktagv7/test.txt?rlkey=wqzs2qbbfazbgj3ttcaik9pq2&dl=1

2. Receive a 302 Found response with this header: Location: https://ucf3d30d8449d3b4b71630f2179a.dl.dropboxusercontent.com/cd/0/get/CUfGJ4UYzNP3f_SeeyAWDmkzqSHo...

3. Follow the redirect URL and get a 400 Bad Request response. Note: the URL above expires quite early, it'll return the 410 response now, but it is expected and not the actual issue.

 

Issue and workaround:

The redirect URL contains the # character at the end which causes the 400 response. It is interesting that both curl and Postman remove this character so that is why it is not reproduced there. Removing this character manually before following the redirect fixes the issue and I can get a valid response in my environment as well.

 

Not sure why this character is a part of the URL and if it is an HTTP rule, Dropbox bug or bug of the underlaying library I'm using, but at least now I have a clean understanding of the issue and a workaround for it. I want to know your thoughts about it and then if it is a library bug, I'll redirect it to its developer :slightly_smiling_face:

View solution in original post

18 Replies 18

Здравко
Legendary | Level 20

Hi @MikkBenelis,

To be sure what's going on you need to dump your request and see what's there. Otherwise it's just a speculation.

 


@MikkBenelis wrote:

Seems like I'm facing the same or really similar issue. Just wanted to try Dropbox for my pet-project read-only data storage and found that it always responds with a 400 status code for a regular GET request.

...


If you just get 400 status, your case is definitely not the same! In the current thread discussed issue is additional symbols added at the request end that result in second response - erroneous of course. The original request is executed correctly though. That's why the response is 200, not 400. If you don't know what's in your cases start investigate from zero. Just supposing is not best guide. :winking_face: In this thread the issue is Texas Instruments library bug that messes the request. If you don't use the same library, then your issue, despite looking similar, cannot be the same.

Good luck.

 

PS: Keep in mind that Dropbox strictly follows HTTP standard. So if in your code is a small "deviation", in spite may tolerated on some places, will be an issue on Dropbox.

Greg-DB
Dropbox Staff

@MikkBenelis As Здравко said, it doesn't sound like this is exactly the same as the original issue in the thread you posted in, so I've moved your message to its own thread.

 

If you still need help with this, please share a sample of the full request and response, including both headers and bodies for both, so we can take a look. Please redact any secret values though.

MikkBenelis
Helpful | Level 5

First of all, there is a chance that this problem is relevant to software I'm using, but when I tried Google Drive and a couple of other direct links for the same task it worked properly. It would be nice if you can help me capture the request details because I don't have low-level access to this library and since it is a TLS request, I can't capture it normally with Wireshark. I can send my minimal executable if it is acceptable, but I think it is better to point me to the way of TLS traffic capturing and decrypting.

 

I'm sending a regular GET request with the manually added "Host" header with the value of "www.dropbox.com" just in case if it is not calculated automatically (I found that it is required in Postman). Below is the actual URL and all of the response details that I have.

 

URL is: https://www.dropbox.com/scl/fi/fc5rwkff82yvy66ktagv7/test.txt?rlkey=wqzs2qbbfazbgj3ttcaik9pq2&dl=1

 

Response code: 400


Headers:
- Content-Length: 1005
- Content-Type: text/html
- Vary: Accept-Encoding
- X-Dropbox-Response-Origin: local
- Date: Mon, 03 Jun 2024 16:39:53 GMT
- Server: envoy
- Connection: close

 

Body:

 

<!DOCTYPE html>
<html>
<head><meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Dropbox - 400</title>
<link href="https://cfl.dropboxstatic.com/static/metaserver/static/css/error.css" rel="stylesheet" type="text/css"/>
<link rel="shortcut icon" href="https://cfl.dropboxstatic.com/static/images/favicon.ico"/>
</head>
<body>
<div class="figure">
<img src="https://assets.dropbox.com/www/en-us/illustrations/spot/target-miss.svg" alt="Error: 400"/>
</div>
<div id="errorbox">
<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>.
</div>
</body>
</html>

 

Greg-DB
Dropbox Staff

A response like that should indicate that the request was malformed, so we'd want to see the raw HTTP request you're sending. Unfortunately we can't provide guidance on how to get that kind of logging from your client though, as the client itself isn't made by Dropbox. You may need to refer to the client's documentation or support resources.

MikkBenelis
Helpful | Level 5

I'm trying to dump the raw HTTP request, but not sure that it'll be possible with the high-level API that I have... Is it possible to track the request on your side? The error message says "the Dropbox team has been notified" so I assume it is logged somewhere and maybe I can provide some sort of request ID or something.

Greg-DB
Dropbox Staff

Unfortunately I can't retrieve the original raw HTTP request itself, even with the request ID.

Здравко
Legendary | Level 20

Hi @MikkBenelis,

I hope you know what netcat is and how it's used. If you transform https://www.dropbox.com/scl/fi/fc5rwkff82yvy66ktagv7/test.txt?rlkey=wqzs2qbbfazbgj3ttcaik9pq2&dl=1 to something like http://localhost:8080/scl/fi/fc5rwkff82yvy66ktagv7/test.txt?rlkey=wqzs2qbbfazbgj3ttcaik9pq2&dl=1 or similar, you'll be able see exactly what's in your HTTP request. :winking_face: Do left everything else the same.

Hope this gives direction.

MikkBenelis
Helpful | Level 5

Hey, you are a genius, simple and clean suggestion :slightly_smiling_face:

As a backend developer, I don't know why I did not thought about it...

 

So the failing library produced this request:

 

GET /scl/fi/fc5rwkff82yvy66ktagv7/test.txt?rlkey=wqzs2qbbfazbgj3ttcaik9pq2&dl=1 HTTP/1.1
Host: www.dropbox.com
Accept-Encoding: gzip, deflate
User-Agent: GodotEngine/4.2.2.stable.official (Windows)
Accept: */*

 

 

And this what was produced by Postman (added headers to match previous request):

 

GET /scl/fi/fc5rwkff82yvy66ktagv7/test.txt?rlkey=wqzs2qbbfazbgj3ttcaik9pq2&dl=1 HTTP/1.1
Host: www.dropbox.com
Accept-Encoding: gzip, deflate
User-Agent: GodotEngine/4.2.2.stable.official (Windows)
Accept: */*

 

 

The only difference is this extra new line at the end. I can't control it since it is an external library. And it means that the issue is exactly the same in original thread where I posted my message. Potentially, we are using same libraries.

Greg-DB
Dropbox Staff

Thanks for the sample! It appears to manifest slightly differently since you're unable to get a success response from a single request, whereas in the original issue an extra new line caused an issue only on the second request on the same connection, not the first request. Regardless, it does sound like the issue is that the client is sending the unexpected new line, resulting in a malformed request. We're looking into it and I'll follow up here with any updates. I can't promise if/when the team will be able to update the server to accept these malformed requests though.

Need more support?
Who's talking

Top contributors to this post

  • User avatar
    Здравко Legendary | Level 20
  • User avatar
    MikkBenelis Helpful | Level 5
What do Dropbox user levels mean?