-
Bug
-
Resolution: Unresolved
-
Low
-
None
-
8.20.10, 9.4.1
-
None
-
8.2
-
3
-
Severity 3 - Minor
-
1
-
Issue Summary
When we enable TRACE logging for com.atlassian.ratelimiting.internal.requesthandler, one of the entries logged shows "is UI request:" data.
It turns out that this ignores the authorization header and if the request is Basic or Bearer (token), it might show an incorrect result which can be misleading.
Reference: Jira rate limiting is not working due to cookies/headers in the requests
Notice that this bug affects trace logging only, and not the functionality itself
This is reproducible on Data Center: yes
Steps to Reproduce
- Enable Rate Limiting
- Enable TRACE logging to com.atlassian.ratelimiting.internal.requesthandler
- Send a few requests so they get throttled.
- They should be either with Basic authentication or use a token
- They should have an Origin and Referer headers
Expected Results
The requests are throttled as expected, and the logs say
... is UI request: [false]
Actual Results
Even though the request is not considered to be UI, the logs show it is:
... is UI request: [true]
Workaround
Check the Authorization header below that message to identify if Jira will consider the request for throttling.
More details at Jira rate limiting is not working due to cookies/headers in the requests
- is blocked by
-
BSP-6390 Loading...