For the moment this bug(s) was only reported OnDemand and we do have some reasons to believe that is also related to the server load.

Expected behaviour: return a JSON response.

Problems:

• 200 means success and should never have an empty body. Empty body success responses are supposed to use code 204 – http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
• An empty body is an invalid JSON response, this not being allowed.
• If it is an authentication failure, this MUST return a 401 or 403 code.
• This is not a real authentication failure because we are 100% sure that the credentials are right (using basic_auth).
• If the server is not able to respond due to other causes it MUST reply with a 503 code and optionally with a Retry-After header that tell the client when to retry the request.

As stated above this bug uncovers several serious HTTP standard deviations, probably caused by several broken pieces of code.

It may be useful not remark this response header and the fact that, so far, all reports were happening while using basic_auth

'x-seraph-loginreason': 'OUT, AUTHENTICATED_FAILED'

Atlassian support suggested, as a temporary workaround, to use alternative authentication options. Still our tests proved that other auth ways are even more prone to fail. Also BASIC_AUTH is documented in several places as the recommended authentication to use with REST, that being one of the reasons we call it REST.