@preinkemeier Thanks for your suggestions. As I understand it, retrying a request with the same credentials after receiving 403 is against RFC 7231 6.5.3:
If authentication credentials were provided in the request, the server considers them insufficient to grant access. The client SHOULD NOT automatically repeat the request with the same credentials. The client MAY repeat the request with new or different credentials. However, a request might be forbidden for reasons unrelated to the credentials.
and RFC 7235 3.1, which should be used instead:
If the request included authentication credentials, then the 401 response indicates that authorization has been refused for those credentials. The user agent MAY repeat the request with a new or replaced Authorization header field (Section 4.2).
This would have severe implications. For instance, if DAVdroid suddently receives 403 while syncing using Basic auth, does that mean that it should try Digest at will for specific resources, too? Or maybe even other authentication methods?
My interpretation is that 403 means: server has understood and accepted user name/password, but the client is not allowed to access the resource with these credentials, while 401 means: unauthorized = credentials not accepted.
Returning 403 instead of 401 is broken behavior and I think it can’t be fixed by client-side workarounds. They will only make it worse. Implementation would also be quite cumbersome and dirty, because the whole authentication concept (of okhttp) relies on correct HTTP status code usage.
DAVdroid tries Basic automatically (without waiting for 401) on HTTPS connections, which shouldn’t cause problems according to RFC 7235 2.1:
A user agent that wishes to authenticate itself with an origin server – usually, but not necessarily, after receiving a 401 (Unauthorized) – can do so by including an Authorization header field with the request.