We are aware of the issue with the badge emails resending to everyone, we apologise for the inconvenience - learn more here.
Forum Discussion
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 🙂
Hm.. 🤔 MikkBenelis, as far as I can see there is no any extra new line in both requests on your screenshot. You said that have one found. Can you clarify what exactly you found out and where it is? It may be useful to post a link to binary dump of your netcat output - there might be something else if not extra new line. No everything is clearly visible as simplest text or terminal screenshot.
Let's see...
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 🙂
MikkBenelis, Yes, I agree that there are lot of bug tolerated services, like you mentioned. The existence of such bug toleration somewhere doesn't change the standard though! It stays the same. 🤷
MikkBenelis wrote:...
Not sure why this character is a part of the URL and if it is an HTTP rule, ...
MikkBenelis, I believe you're receiving email notifying you about my current post. Take a closer look on the link pointing my post. Can you see there something similar to that you are not sure is it HTTP rule? 🧐🙋 Something else you may try - navigate to the same page starting from www.dropboxforum.com and directly using the link pointing my post. Note that in the first case the page top comes up, but in the second one - directly my post. 🤔🤷 In addition take a look on the HTTP requests themself. Is there any difference between them?... In such a case, why does different page view appear? 😯 In fact it's the same page, received with the same request! 🤫
Ok, the last URL construct (named anchor), that starts with hash(#) and may have others following symbols, is absolutely valid construct. 🙂 That construct carries kind of parameter(s) targeting HTTP client, not server - some additional information that may affect client work, including (but not limited to) how the resulting view appears. Such information doesn't appear in any HTTP request (or should not at least). Server receives the classical params only - between question mark, if any, and hash (or till the URL end). The hash symbol (and all after that) should misses in the request. 😉
MikkBenelis wrote:..., Dropbox bug or bug of the underlaying library I'm using, but at least now I have a clean understanding of the issue ...
Hm...🤔 ...and is it a Dropbox bug or a bug in your underlying library? What did you conclude based on where that "cut" should happen? 😉
Good luck.
ЗдравкоI knew that it is usually used to scroll the page to a specific section or highlight some region of interest if a user agent supports it, but did not know that it should never be sent back to server... My conclusion that there is a bug in both Dropbox and the URI specification itself 😁
Imagine you had a link www.abc.com/qwe#asd, then it was moved to www.abc.com/qwert#asdfg and you want to apply a 301 redirect to it. You can't do it with Dropbox, it'll respond with a 400 error. This part is called Fragment, here is the related RFC section https://datatracker.ietf.org/doc/html/rfc3986#section-3.5
Why is it a Dropbox bug? IMHO, it should not send a URI with the number sign character without anything after it, especially for such redirects. Also, I think that this part should be excluded on a server if it has no special meaning there, but it should not respond with the 400 error. Most of the servers (just tried a couple of Google links) can use or exclude it and the request will be processed normally.
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
