You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
ram4444
2 years agoExplorer | Level 4
Service Unavailable 503
https://api.dropbox.com/oauth2/token?grant_type=refresh_token&refresh_token=<REFRESH_TOKEN>&client_id=<MYAPPID>&client_secret=<MYSECRET>
When I http POST to the above URL for refreshing Access ...
- 2 years ago
ram4444 Thanks for following up and sharing that, and apologies for the delay. (It appears your latest message may have initially been caught in a spam filter.)
Anyway, I see your client is sending a "TE" header in the request, but no "Connection" header. According to the specification, the corresponding "Connection" header value is required when setting the "TE" header. I am able to reproduce the error you see when setting "TE" and not "Connection", and I am able to resolve the error by setting both "TE" and "Connection" (specifically, "Connection: TE"). If you are not able to remove the "TE" header your client is setting, you should try to have it set "Connection: TE" as well.
ram4444
Explorer | Level 4
Below is what I obtain when I toString() the POST request.
I include headers same as what they are in POSTMAN (as they are generated automatically by POSTMAN) as well
--> POST https://api.dropbox.com/oauth2/token?grant_type=refresh_token&refresh_token=REDACTED&client_id=REDACTED&client_secret=REDACTED
Body : (empty)
Headers : (6)
Connection : keep-alive
User-Agent : PostmanRuntime/7.32.2
Accept : */*
Accept-Encoding : gzip, deflate, br
Cookie : locale=en; t=RzvutB7WDW79g72wIY13TQgy
Content-Length : 0
However, no matter these headers are/not put in my code or not, the result status is still 503.
So I believe that there are something blocked on the API side to prevent my POST sending from JVM only but not the POSTMAN
Здравко
2 years agoLegendary | Level 20
Hi again ram4444,
If you have troubles with dumping your application communication, there is still a workaround that can help you figure out what exactly flows on the wire. 😉 It's simple; just create a pseudo server that just dumps everything incoming using netcat and do redirect your failing call temporary to this server to see what's going on. For instance such a "server" can be created with following command running in a terminal:
netcat -s localhost -p 8080 -l
Next, temporary in your application, replace everywhere you're using something like:
https://api.dropbox.com/oauth2/token?grant_type=...
... to something like following:
http://localhost:8080/oauth2/token?grant_type=...
Recompile and prepare your application for run. Next run the pseudoserver above and your application immediately after that. 🙋 Now you should be able see exactly what Dropbox server "api.dropbox.com" sees in your terminal and evaluate what's wrong. You can do the same experiment with your POSTMAN and see what's different. 😉
Good luck.
PS: The "toString()" method result is rarely usable to debug such thing especially when the type that would be represent as a string doesn't impose such use case (debug). For instance your first line cannot be correct; neither host nor scheme can be there, but it's rather stringification implementation details, not mandatory a direct error! So cannot be used for conclusion or diagnostic...
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
5,886 PostsLatest Activity: 33 minutes agoIf you need more help you can view your support options (expected response time for an email or ticket is 24 hours), or contact us on X or Facebook.
For more info on available support options for your Dropbox plan, see this article.
If you found the answer to your question in this Community thread, please 'like' the post to say thanks and to let us know it was useful!