As mentioned above picture, I should get these headers in response when I receive 429, but I'm not getting these headers.
Here are the status code and response headers that I'm getting:
429
{
server: 'AtlassianProxy/1.15.8.1',
vary: 'Accept-Encoding',
'content-type': 'text/html;charset=ISO-8859-1',
'strict-transport-security': 'max-age=315360000; includeSubDomains; preload',
date: 'Tue, 06 Apr 2021 12:03:12 GMT',
'atl-traceid': 'caa2c0619953d843',
'x-xss-protection': '1; mode=block',
'x-envoy-upstream-service-time': '15',
'x-content-type-options': 'nosniff',
connection: 'close',
'expect-ct': 'report-uri="https://web-security-reports.services.atlassian.com/expect-ct-report/global-proxy", enforce, max-age=86400',
'content-length': '1922'
}
Hi @Lalit Kumar
Sorry to hear about this problem. However I believe that the documentation you are referring to here is for our Jira Server/Data Center editions as seen in https://confluence.atlassian.com/adminjiraserver/improving-instance-stability-with-rate-limiting-983794911.html
However this Community posts makes it appear that you might be using Jira Cloud instead. For Jira Cloud, we have documented the rate limit behavior a little differently over in https://developer.atlassian.com/cloud/jira/platform/rate-limiting/ in that page the exact wording is
Retry-After headers
429
responses may be accompanied byRetry-After
andX-RateLimit-Reset
headers.
Retry-After
indicates how many seconds the app must wait before reissuing the request. If you reissue the request before the retry period expires, the request will fail and return the same or longerRetry-After
period.
X-RateLimit-Reset
indicates the date time when you can retry the request. It’s provided in the format:yyyy-MM-ddTHH:mmZ
.Some transient
5XX
errors are accompanied by aRetry-After
header. For example, a503
response may be returned when a resource limit has been reached. While these are not rate limit responses, they can be handled with similar logic as outlined below.
As such, not all the same headers are included in the Cloud REST response and not all 429 responses will include a retry-after in the response Cloud.
The rate limiting in Cloud is continuously evolving based on numerous factors. Hence you are not as likely to get this specific header in Cloud as you might get back from a Server/Data Center edition. Instead our Cloud rate limiting documentation suggests applying a jitter to the delay and using an exponential backoff strategy if you are creating an app to make such REST API calls.
I hope this helps.
Andy
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.