[13-0.7 & 14.0.2] /.well-known/caldav and carddav

[terrar]

Steps to reproduce

1. Upgrade from 13.0.7 to 14.0.2 and also from 14.0.1 to 14.0.2

Expected behaviour

Upgrade without errors

Actual behaviour

Error message:
Dein Web-Server ist nicht richtig eingerichtet um "/.well-known/caldav" aufzulösen. Weitere Informationen findest Du in der Dokumentation.
Dein Web-Server ist nicht richtig eingerichtet um "/.well-known/carddav" aufzulösen. Weitere Informationen findest Du in der Dokumentation.

Server configuration

Operating system: Ubuntu 16.0.4

Web server: apache2

Database: mysql

PHP version: 7

Updated from an older Nextcloud/ownCloud or fresh install: upgrade

This .htacces settings should not produce the error message above i think:
(they were generated automatically but it seems hey do not work)

<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteCond %{HTTP_USER_AGENT}  DavClnt
  RewriteRule ^$         /remote.php/webdav/          [L,R=302]
  RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
  RewriteRule ^\.well-known/host-meta /public.php?service=host-meta [QSA,L]
  RewriteRule ^\.well-known/host-meta\.json /public.php?service=host-meta-json [QSA,L]
  RewriteRule ^\.well-known/carddav /remote.php/dav/ [R=301,L]
  RewriteRule ^\.well-known/caldav /remote.php/dav/ [R=301,L]
  RewriteRule ^remote/(.*) remote.php [QSA,L]
  RewriteRule ^(?:build|tests|config|lib|3rdparty|templates)/.* - [R=404,L]
  RewriteCond %{REQUEST_URI} !^/\.well-known/(acme-challenge|pki-validation)/.*
  RewriteRule ^(?:\.|autotest|occ|issue|indie|db_|console).* - [R=404,L]
</IfModule>

[nextcloud-bot]

GitMate.io thinks possibly related issues are #11752 (13.0.7), #11751 (14.0.2), #8766 (Caldav ), #11713 (13.0.7 RC 2), and #2649 (Upgrade from 10.0.2 to 11.0.0 breaks carddav and caldav URIs).

[shieldwed]

Same behaviour here. Before the upgrade this message wasn't displayed. I don't think there's a real problem though, as my synchronization with DAVdroid is still working after the upgrade. Just the message keeps saying that there is a misconfiguration.

My setup is nextcloud fpm in the official docker images with an nginx webserver in front of it. I didn't change my webserver configuration regarding these well-known URLs for the upgrade though.

[timm2k]

This should be fixed with PR #11738. May opcache isn't recognizing a new php source file?

[MorrisJobke]

Background of this:

• /.well-known/caldav is a autodiscovery URL - that means it is only used during a setup of a sync
• this URL is used so that the end user don't need to know the full URL of the service, but only the domain - then this URL is a redirect to the actual URL of CalDAV
• this URL always needs to be in the root of the domain: https://cloud.example.com/.well-known/caldav and not in https://cloud.example.com/nextcloud/.well-known/caldav
• Nextcloud is installed into the root: we can register the URL within apache automatically via the htaccess file only if the nextcloud is installed in the root as well
• Nextcloud is installed into a subfolder: the admin needs to setup the proper redirect in the Webserver itself, because this is out of the scope of Nextcloud - this basically means that https://cloud.example.com/.well-known/caldav should point to https://cloud.example.com/nextcloud/remote.php/dav

Does that helps to understand the problem here?

[MorrisJobke]

See also https://docs.nextcloud.com/server/14/admin_manual/issues/general_troubleshooting.html#service-discovery for this.

[MorrisJobke]

I guess that all your instances are in a subfolder, which then explains this message. The check itself was broken before 14.0.2 and thus didn't showed up. I will close this. If this is not the case for your instance we are happy to help with further steps.

[9R]

I am seeing the same error message since the update to 14.0.2.
I am running Nextcloud in the root of the domain on a nginx. The redirects in the webservers config are configured as suggested in the documentation and when accessing the .well-known links remotely as well as locally they are redirected to remote.php/dav as expected.
So I suspect the check fails in some cases although the redirects actually work.

[MorrisJobke]

So I suspect the check fails in some cases although the redirects actually work.

Could you open the webdev tools in your browser and check the network tab for what it actually requests and what the response is? Open the network tab and then refresh the admin page to see all requests.

[terrar]

I get this error here on FF. (apache2)

[9R]

Could you open the webdev tools in your browser and check the network tab for what it actually requests and what the response is? Open the network tab and then refresh the admin page to see all requests.

Request:
Request-URL: `https://foo.bla/.well-known/caldav`
Request method: PROPFIND

Response-Header:
content-length: 185
content-type: text/html
date: Fri, 12 Oct 2018 09:30:23 GMT
location: `http://foo.bla/remote.php/dav`
referrer-policy: no-referrer
server: nginx/1.14.0
strict-transport-security: max-age=15768000
x-content-type-options: nosniff
x-download-options: noopen
X-Firefox-Spdy: h2
x-permitted-cross-domain-policies: none
x-robots-tag: none
x-xss-protection: 1; mode=block

[ptrunk]

I think the problem here is that we are redirected from https to http which is denied by "Content Security Policy". I have the same problem with my nginx + fpm docker setup after the 14.0.2 update

[9R]

Ah, right. I forgot to mention that. In my case the nginx running Nextcloud is behind a reverse proxy handling ssl. That proxy redirects all http request to https which has not caused any problems yet.

Changing the redirect rule for in the nginx config for Nextcloud-site from

return 301 $scheme://$host/remote.php/dav;

to

return 301 https://$host/remote.php/dav;

to force connection directly via https fixed the issue for me.

[MorrisJobke]

@ptrunk @9R Does this also solve the issue for you?