Receiving 301 statusCode when trying to use Nextcloud and DAVx5

While trying follow this guide (https:// www on DAVx5 official webpage, I got the following exception:

at.bitfire.dav4jvm.exception.HttpException: HTTP 301 Moved Permanently
at at.bitfire.davdroid.ui.setup.NextcloudLoginFlowFragment$LoginFlowModel.postForJson(NextcloudLoginFlowFragment.kt:19)
at at.bitfire.davdroid.ui.setup.NextcloudLoginFlowFragment$LoginFlowModel.access$postForJson(NextcloudLoginFlowFragment.kt:1)
at at.bitfire.davdroid.ui.setup.NextcloudLoginFlowFragment$LoginFlowModel$checkResult$1.invokeSuspend(NextcloudLoginFlowFragment.kt:13)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:3)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.kt:1)
at kotlinx.coroutines.scheduling.CoroutineScheduler$

Request{method=POST, url=, headers=[Accept-Encoding:br,gzip]}

Response{protocol=http/1.1, code=301, message=Moved Permanently, url=}

301 Moved Permanently

301 Moved Permanently


The login process accessing the “Sync calendar & contacts” option on nextcloud app is as follows:

  • Select “Sync calendar & contacts”,
  • The Nexcloud App calls DAVx5 app
  • DAVx5 calls the system default browser to proceed with the login

Curiously, while on the login process, the browser warned me that the information i was passing “wasn’t secure” (but I’m pretty sure I’m both logged in with https on Nextcloud and my login process was using my Primary CalDav Address, which is https:// my and then, when I’m promped to close the browser, the DAVx5 app throws the exception above.

As the http request is made on opendesktop(dot)org, which also gives the response, I’m prone to believe that here is where I should post this issue.

So, what is happening? Why is this response being sent?

Confirmed right now that this is a problem with OpenDesktop itself. Tried other providers and the configuration went ok.

It is not entirely clear to us where exactly the problem is. The Nextcloud desktop app shows a similar behavior. Here, in the middle of the authorization process, only the http protocol is used instead of https. Our server tries to respond with a redirect to https, but the application doesn’t seem to understand that. After several attempts, it worked with the desktop app.

We will try to solve the problem with one of the next updates.

Sorry that we can’t help right away.