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
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 ...
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.
The request contains only the parameters but no header/body specified
val url = "https://api.dropbox.com/oauth2/token?grant_type=refresh_token&refresh_token=$longTimeRefreshToken&client_id=$clientId&client_secret=$clientSecret"
My code is Kotlin and I am using Fuel as the HTTP Library (which is on top of OKHTTP)
I tried in POSTMAN and the result is normal
Greg-DB
Dropbox Staff
Dropbox Staffram4444 I understand you're including the parameters on the URL itself, but the actual HTTP request issued by your client would involve some start line and header(s) at least. So that we can investigate the request that causes that error, please print out and share the actual HTTP request itself. You may need to refer to the documentation for your client for information on how to enable more verbose output to show the request.
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 : 0However, 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
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...
- Greg-DB
ram4444 As Здравко said, your output may not actually be representative of the real request. I tried replicating the request in curl using the header values you supplied, but the call succeeded for me. That may indicate that the output in fact does not sufficiently show what the actual request consists of.
That being the case, you may want to use the technique that Здравко helpfully provided to try to see what the difference is.
By the way, they've been redacted from the post, but I see that you originally included your refresh token, app key, and app secret in your most recent message. Since those were publicly posted for a time though, I suggest revoking the refresh token. You can do so by calling /2/auth/token/revoke using a short-lived access token for that refresh token, which would revoke that refresh token as well as any/all short-lived access tokens for that refresh token. You can use the API v2 Explorer to perform the call. You'd then need to re-authorize the app to get a new refresh token. If the app is in development mode, you can also delete and recreate the app itself from the App Console to invalidate the app key/secret; that would also disable any/all access tokens/refresh tokens for the app as well, and you'd need to update the app to use the new key/secret.
Thanks for Greg-DB and Здравко advices. I have located the problem is the Header TE generated from FUEL itself. After putting it to the POSTMAN request I can replicate the status code 503
User-Agent: FUEL
Accept: */*
Accept-Encoding: gzip, deflate, br
Cookie: locale=en; t=RzvutB7WDW79g72wIY13TQgy
Content-Type: text/plain; charset=UTF-8
TE: gzip, deflate; q=0.5As I still cannot find any way to remove this header from the request of my code, may I know why the server will handle it and cause error (so that it can be simply ignored when receive?)
About Dropbox API Support & Feedback
Find help with the Dropbox API from other developers.
