Child Item

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 Token in my code, a 503 service unavailable is returned.

However there is no any issue when I do the same thing in POSTMAN

Any body ever had this issue before? Am I missing something in the HTTP header/body?

Find more posts tagged with

API

Abuse

Accepted answers

Greg-DB

@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.

All comments

Здравко

@ram4444 wrote:
...
When I http POST to the above URL for ...

Hi @ram4444,

How exactly have you posted the above URL? 🤔 The URL looks like a GET URL! What did you post in the body of your POST request? 🧐 Take in mind that only changing the method name is NOT enough (in spite error check of Dropbox API seems compromised). 😉

Greg-DB

@ram4444 Can you share the full HTTP request (headers and body, if any) that results in a 503 so we can look into it? Be sure to redact your refresh token, app key, and app secret values though. Please also share the full response (headers and body, if any) for reference. Thanks in advance!

ram4444

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

@ram4444 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.

ram4444

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

Здравко

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.

ram4444

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.5

As 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?)

Greg-DB

@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.)

ram4444

@Greg-DB Great thanks for your advice and now I can send out the refresh token request.

& @Здравко Thanks for your recommendation in looking into the full HTTP request