Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upgrade from 10.0.2 to 11.0.0 breaks carddav and caldav URIs #2649

Closed
awlx opened this issue Dec 13, 2016 · 11 comments
Closed

Upgrade from 10.0.2 to 11.0.0 breaks carddav and caldav URIs #2649

awlx opened this issue Dec 13, 2016 · 11 comments
Assignees
Labels
0. Needs triage Pending check for reproducibility or if it fits our roadmap bug feature: dav

Comments

@awlx
Copy link

awlx commented Dec 13, 2016

After a upgrade from 10.0.2 the URIs of /caldav and /carddav changed to /dav which breaks older clients. And I had to do some rewrites on my machine:

Nginx config:

   if ($request_uri ~ /nextcloud/remote\.php/caldav/calendars/(.*)$  ) {
            set $request_url /nextcloud/remote.php/dav/calendars/$1;
    }
    if ($request_uri ~ /nextcloud/remote\.php/carddav/addressbooks/(.*)$) {
            set $request_url /nextcloud/remote.php/dav/addressbooks/$1;
    } 

Expected behaviour

When a client requests:
https://cloud.org/nextcloud/remote.php/caldav/calendars/(user)/defaultcalendar

It should get the answers as before the upgrade.

Actual behaviour

Client gets a 404 because real URI changed to https://cloud.org/nextcloud/remote.php/dav/calendars/(user)/defaultcalendar

Same for carddav

Server configuration

Operating system:
CentOS release 6.8 (Final)

Web server:
nginx version: nginx/1.10.2

Database:
mysql Ver 14.14 Distrib 5.5.52, for Linux (x86_64) using readline 5.1

PHP version:
5.6.28
Nextcloud version: (see Nextcloud admin page)
11.0.0
Updated from an older Nextcloud/ownCloud or fresh install:
Update from 10.0.2 to 11.0.0

@LukasReschke LukasReschke added 0. Needs triage Pending check for reproducibility or if it fits our roadmap bug labels Dec 13, 2016
@LukasReschke
Copy link
Member

cc @rullzer

@smirkybg
Copy link

Sorry but can you share with the rest of the class where and what you edited to make it work?
Thank you!

@awlx
Copy link
Author

awlx commented Dec 13, 2016

I put the rewrites in the nginx config.

@smirkybg
Copy link

I can't make it work with your workaround. I even tried to tweak it for my config, but still no success.
I guess I'll wait for something more official and see where that goes. Shame I can't use my contacts because of this now

@LukasReschke
Copy link
Member

@rullzer Told me he takes a quick look. Roeland, if you have no time or disagree feel free to reassign :)

@smirkybg
Copy link

location / {
	# The following 2 rules are only needed with webfinger
	rewrite ^/.well-known/host-meta /public.php?service=host-meta last;
	rewrite ^/.well-known/host-meta.json /public.php?service=host-meta-json last;
	rewrite ^/.well-known/carddav /remote.php/dav/ redirect;
	#rewrite ^/.well-known/carddav /remote.php/carddav/ redirect;
	#rewrite ^/.well-known/caldav /remote.php/caldav/ redirect;
	rewrite ^/.well-known/caldav /remote.php/dav/ redirect;
	rewrite ^(/core/doc/[^\/]+/)$ $1/index.html;
	try_files $uri $uri/ /index.php;
}

I nailed it for my config :)

@awlx
Copy link
Author

awlx commented Dec 13, 2016

I can't make it work with your workaround. I even tried to tweak it for my config, but still no success.
I guess I'll wait for something more official and see where that goes. Shame I can't use my contacts because of this now

Well it might have some specials for my nginx configuration. Like the variables request_uri and request_url which might be named otherwise in yours.

rullzer added a commit that referenced this issue Dec 13, 2016
Fixes: #2649

Seem that this code is now obsolete and actually breaks the old
endpoint. Since we request the current principal which then gets
converted to 'principals/users/<user>' but in the old endpoint we work
with 'principals/<user>'

Signed-off-by: Roeland Jago Douma <roeland@famdouma.nl>
@rullzer
Copy link
Member

rullzer commented Dec 13, 2016

#2653 should (tm) fix the issue. Please have a look.

@N8Fear
Copy link

N8Fear commented Jan 3, 2017

#2653 applied on top of normal 11.0.0 doesn't fix the issue for me (so unless there is something else that has sideeffects in one of the other commits, I'd consider it still unfixed).

@rullzer
Copy link
Member

rullzer commented Jan 4, 2017

@N8Fear please try #2685

@rullzer
Copy link
Member

rullzer commented Mar 14, 2017

The tests now run also against the old endpoint and pass. If somebody encounters other issues please open a new issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
0. Needs triage Pending check for reproducibility or if it fits our roadmap bug feature: dav
Projects
None yet
Development

No branches or pull requests

5 participants