However executing curl -X PROPFIND -k -i -u philippr:MY_PASS https://XXX.de/calendars/users/philippr/calendar/ gives
HTTP/1.1 403 Forbidden
So this is exactly what DAVdroid receives.
My guess is that this is related to DAVdroid immediately trying to use basic auth when a HTTPS URL is used. In this case, it gets 403 by the server, because it only supports digest auth.
If the server is configured properly, it will return 401 in this case and tell DAVdroid that only Digest is supported. DAVdroid will then retry the request with Digest.
Could DAVdroid be improved by trying both, basic auth and digest auth if it gets 403 before giving up?
As said above, this seems to be a server problem. 403 means Forbidden, and a client should not try again that request. If you want to tell a client that it shall use Digest, you’d have to use 401 for that.
Does that help?
Well… No. I cannot use DAVdroid with the current server configuration. But i understand your argument and agree that the response by the server is not really what one would expect.
Given that other clients Like Thunderbird, CalDAV-Sync and CalDAV Sync Free Beta just work, the situation is still disappointing though.
This makes me think of another approach: What If DAVdroid would, only during account setup, first try to PROPFIND the specified URL without sending any authorization header. The server then has to respond with the requested kind of authorization and DAVdroid could then choose the one requested by the server. To me this sounds like a more robust strategy, which is also more in line with how the http authorization framework is expected to work. Of course this comes with the cost of additional HTTP requests, but this could be limited to the account setup. Later synchronizations done by DAVdroid could simply use the authorization scheme detected during account setup.
What do you say?
Which server software are you using?
The DAVdroid log says “Server: Twisted/8.1.0 TwistedWeb/[twisted.web2, version 0.2.0] TwistedCalDAV/1.2 >”
However i die not verify this.
And just for curiosity: Is there any reason to use Digest over HTTPS?
Personal preference by the admin i think… Don’t know.