Need to see if your shared folder is taking up space on your dropbox 👨💻? Find out how to check 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.
- Greg-DB
Dropbox Community Moderator
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.
MikkBenelis wrote:...
The only difference is this extra new line at the end. I can't control it since it is an external library. ...
Hm..🤔 Honestly I'm not familiar with that environment you're using, but as far as I can see it's .NET based. In such a case (if I'm not in confusion), why at all additional engine would be needed at all. .Net is able to perform HTTP request successful! Use the available underlying engine instead of reimplemented buggy one that you don't know where is coming from. 😉 I believe this will be possible.
Good luck.
PS: For long term solution try replace your requests responsible code with non buggy or ask the supplier to debug its code (e.g. signal for the bug).
By the way, usually most libraries return one result matching to one corresponding request. If by mistake unexpected request (correct or incorrect) comes up, result is either first or last one. As seems in your case the result got back is the last one (carrying the error) - opposite to the OP. 🙋
Of course, this is rather speculation.
ЗдравкоThe environment I'm using supports two languages: C# (.NET) and GDScript (or both). I'm using GDScript-only version for this application which as I understand relies on its own HTTP client implementation probably with libcurl and mbedtls libraries. I already reported it, but had to find some details since everything except Dropbox worked fine.
I lost a link so not sure what was the first request of the OP, but if I remember clear it was PUT, POST or something with the body while the second one was regular GET. While testing with netcat I found that this extra line is a line where request body starts and since it is empty, this line is empty as well (looks like an extra line, but it is actually an empty body). Pretty sure that the HTTP specification allows this new line since all the rest test subjects are working fine. I found only that the GET body should be ignored since it has no meaning, but it doesn't say that I can't send it. Hope it'll be allowed by Dropbox (at least an empty GET body), but seems like I need to search for alternatives for now...
MikkBenelis wrote:... I understand relies on its own HTTP client implementation probably with libcurl and mbedtls libraries. ...
MikkBenelis, mbedtls has nothing to do with HTTP formation; it, if used, is responsible for encryption only. libcurl, if used, works perfectly fine! I personally tested it and it works. Even more the curl command built on top of libcurl is referred tool for testing Dropbox API - again working flawlessly. 🤔🤷 Are you sure libcurl is in use? 🧐 I planned to advise you use exactly this library if possible - just wasn't sure if the environment has such an option. Don't suppose, instead make it sure! 🙋
MikkBenelis wrote:...
I lost a link so not sure what was the first request of the OP, but if I remember clear it was PUT, POST or something with the body while the second one was regular GET. ...
The thread is here. Dropbox API primary uses POST requests. Your question is not related to API actually, but to regular download code - something you should not think at all usually. There must be some error in your environment or you have miss-configured something.
MikkBenelis wrote:... I found that this extra line is a line where request body starts and since it is empty, this line is empty as well (looks like an extra line, but it is actually an empty body). ...
Ha..😁 MikkBenelis, As a backend developer, you should not use/state something like that. Is a line (empty or not) some empty body (recall - empty body means empty content, including string)? Is a new line string an empty string? 🙂 Take a bit more care.
In addition you may take a look on MDN definition for HTTP request or the same on RFC 2616. Can you see somewhere there that either on place of empty body has to be a new line or non empty body has to end with extra new line that is not part of the content length? 😉
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
