It’s not possible to exactly show “unauthorized”, because it doesn’t mean an error when some parts of the auto-detection fail with “unauthorized”. We have carefully thought about this and the solution is to show a generic error message plus logs if you’re interested in details.

If you have specific suggestions on which parts of the auto-detection process can be changed in a certain way, please let us know.

There must be some way for the server to communicate, when the server io properly configured, that only the password does not match to the user name. Evolution e.g. insists on getting XML answers — https://gitlab.gnome.org/GNOME/evolution/issues/59 .

“401 Unauthenticated” means the password is wrong. If the server means something different, it shall use different code.

401 on /.well-known/caldav means the the same: it does not matter, if the server first sends “301 Moved permanently” to /dav/calendars and on the second call returns 401, or if the server returns 401 on the first call.

That said, DAVdroid shall always present 401 to the user as “bad password or user name”.

401 on /.well-known/caldav means the the same: it does not matter, if the server first sends “301 Moved permanently” to /dav/calendars and on the second call returns 401, or if the server returns 401 on the first call.

This only works if the server understands well-known URLs. If it does not support them (and there’s no obligation to do so), /.well-known/caldav may belong to another realm as the actual CalDAV service. So 401 for /.well-known/caldav can mean that

credentials are required/wrong for the CalDAV service, or

credentials are required/wrong for the realm which contains /.well-known/caldav (this could for instance be a realm for everything except /caldav).

That said, DAVdroid shall always present 401 to the user as “bad password or user name”.

This can lead to a “bad password or username” message although, for instance, the base URL was wrong, which would be highly confusing. We had such cases. Assume the user-given URL: /public/wrongcaldavpath/

DAVdroid sends PROPFIND on /public/wrongcaldavpath/, server returns 404 because the path doesn’t exist and /public is not password-protected.

DAVdroid sends PROPFIND on /.well-known/caldav, server returns 401 because .well-known belongs to some protected realm which is not even related to CalDAV/CardDAV, so the credentials are wrong.

Result: DAVdroid has received 404 and 401. If it would give precedence to 401, it would show “wrong username/password” although the base URL was wrong.

On a user-given URL that is nit of the form https://server/, but https://server/path, DAvdroid shall not try try .well-known addresses, but tell the input is invalid. So there are no 404 and 401 at the same time.

@дилян-палаузов Sometimes, there’s a special URL that shall be checked (for instance, because it’s not available over auto-detection), while well-known URLs reveal other collections.

Resource detection must be thought as a big thing with many special cases, which all should work and be as compatible as possible. Fiddling around with only some cases might break other cases.

In my opinion, resource detection consists of checking various resources, so whatever HTTP response there is for one resource, it can’t be shown as “the” result. What could be done is as soon as there is at least one 401, an additional “Username/password wrong?” could be added to the message.

Sure. Many cases, complex thing. Still, if a user enters special, undiscoverable URL, which happens to be 404 invalid, DAVdroid shall communicate this to the user and not try the .well-known addresses.

I am addressing the raised concerns here, stating in which cases 401 means invalid username/password. E.g. when the .well-known/ addresses are not fetched and thus no 404 comes from them.

An additional wrong username/password on 401 is an improvement, but I think in some cases it can mean only this and not lead to a misleading ”Couldn’t find CalDAV/CardDAV service“.