Your workflow is unique 👨💻 - tell us how you use Dropbox here.
Forum Discussion
Solved
400 status code for a regular GET request
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...
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_SeeyAWDmkzqSHoJk98QNNmD7g4NUoVFnAS6PpVPrCmKLfGBS9_fNsxCkcNG3dT40ygtSc8ceWPxLQYy-NiCrRMDxJ-5u_ZftDOnRmXk-ta_m1czPFq5KRSEvknl3F7pFjk01onJrqL/file?dl=1#
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 🙂
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. 😉 Do left everything else the same.
Hope this gives direction.
Hey, you are a genius, simple and clean suggestion 🙂
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.
About Dropbox API Support and Feedback
Get help with the Dropbox API from fellow developers and experts.
