False Warning: Your web server is not properly set up to resolve "/.well-known/caldav"

Frnk · April 19, 2024, 12:02pm

Everybody knows this warning. The forum is full of it.
But can someone tell me, what exactly does Nextcloud check to issue that warning?

At my case it is simply not true:
I point my broswer to the mentioned URL and I am redirected to e.g. “…/remote.php/dav” which is exactly as intended! The page there says:

“This is the WebDAV interface. It can only be accessed by WebDAV clients such as the Nextcloud desktop sync client.”

Which is also the desired behavior. CalDAV-Client also works without complaining, so why do I have that warning.

What is the test the Nextcloud is performing here to decide to display that warning?

Thanks.

tflidd · April 22, 2024, 11:48am

I don’t know if that check is done via js, or from the server itself. If the server calls such resources itself (from the server), it might look different than from external. Therefore, it is better to rely on tests done from the outside. Perhaps a look in the log filese of the webserver can reveal a bit more (e.g. it ends up in a different vhost, …).

It seems to be from php directly:

github.com

nextcloud/server/blob/deac58ab7ee75e0081dd76af3f756ae4c218d207/apps/settings/lib/SetupChecks/WellKnownUrls.php#L65


      
          	public function getName(): string {
          		return $this->l10n->t('.well-known URLs');
          	}
          
          	public function run(): SetupResult {
          		if (!$this->config->getSystemValueBool('check_for_working_wellknown_setup', true)) {
          			return SetupResult::info($this->l10n->t('`check_for_working_wellknown_setup` is set to false in your configuration, so this check was skipped.'));
          		}
          
          		$urls = [
          			['get', '/.well-known/webfinger', [200, 404], true],
          			['get', '/.well-known/nodeinfo', [200, 404], true],
          			['propfind', '/.well-known/caldav', [207], false],
          			['propfind', '/.well-known/carddav', [207], false],
          		];
          
          		foreach ($urls as [$verb,$url,$validStatuses,$checkCustomHeader]) {
          			$works = null;
          			foreach ($this->runRequest($verb, $url, ['httpErrors' => false, 'options' => ['allow_redirects' => ['track_redirects' => true]]]) as $response) {
          				// Check that the response status matches
          				$works = in_array($response->getStatusCode(), $validStatuses);

Frnk · April 25, 2024, 6:19pm

Thanks for the answer. You linked file is what I wanted to know, so I will mark this as ‘solved’.

In reality, that file will just exist in a more up-to-date version, perhaps 29, but I am currently still on 28, where it was not yet implemented that way. (I suppose some core refactor will occur at some point).

Anyway, the problem has gone away for me also. It was a new install on a freshly moved subdomain, so - as you said - from the server itself the result of those tests obviously might have looked diffferent than from my workstation.

Thanks!