Core: Clean URL for dav endpoint and OCS

[DeepDiver1975]

Current situation

As of today the dav endpoint used by any client is named /remote.php/dav. The ocs endpoint is named /ocs/v1.php and /ocs/v2.php.

Following the clean url principle we shall get rid of implementation specific file extension .php

Proposal for dav

use /remote/dav - we can define a rewrite rule to redirect /remote/ to /remote.php
use /ocs/v1/ and /ocs/v2/ - by defining a rewrite rule as well

How do clients know which endpoint to choose?

CalDAV and CardDAV define service discovery mechanisms using .well-known - see http://sabre.io/dav/service-discovery/

We already define rewrite rules for CalDAV and CardDAV - dav and ocs can be added easily:
```
RewriteRule ^.well-known/carddav /remote.php/dav/ [R=301,L]
RewriteRule ^.well-known/caldav /remote.php/dav/ [R=301,L]
RewriteRule ^.well-known/webdav /remote.php/dav/ [R=301,L]
RewriteRule ^.well-known/ocs/v1 /ocs/v1.php [R=301,L]
RewriteRule ^.well-known/ocs/v2 /ocs/v2.php [R=301,L]

[ownclouders]

GitMate.io thinks possibly related issues are https://github.com/owncloud/core/issues/23269 (Consider new DAV endpoint for public shares), https://github.com/owncloud/core/issues/30784 (Provide DAV endpoint to directly access favorites), https://github.com/owncloud/core/issues/31706 (Use new DAV endpoint in web UI for download URL), https://github.com/owncloud/core/issues/24776 (Cannot move files using new dav endpoint ), and https://github.com/owncloud/core/issues/25112 (webdav endpoints).

[michaelstingl]

@owncloud/desktop-core-developers @owncloud/android-core-developers @owncloud/ios-core-developers Is this something clients could check and support?

[ogoffart]

As for the desktop client, redirect support was only added recently (maybe 2.4 only), and even then, i'm not sure this would work for PUT or POST. (So making existing endpoint a redirection is not really an option. I know this is not what is proposed here)
And in general, I don't want the dav endpoint to redirect on every request, that would add a round-trip on every request that would have a significant impact of perf.

Adding a single request, when connecting, to check a redirection on one URL is fine.

[DeepDiver1975]

There is no redirect involved. The rewrite rule is handled in Apache.
The only additional Task for the clients would be to call well-known to understand where to Connect to on Account Setup

[felix-schwarz]

The new iOS SDK currently already goes through several requests while making a connection:
1) status.php: to determine the version and for multi-tenancy support
2) ocs/v1.php/cloud/user: to determine the username of the logged in user
3) ocs/v1.php/cloud/capabilities: to determine the capabilities of the server
4) (there may be more that I don't remember right now)

As I see it, service discovery would

• add additional requests between 1 + 2 for _every_ endpoint used
• need to be run not just during account setup: what if the endpoints change?
• create additional attack surface: imagine an attacker who has power of .well-known, but not the ownCloud instance itself. They could redirect users to a malicious endpoint.

Therefore - while I think service discovery is a great feature for interoperability with software that's targeting open standards - I believe service discovery is not the right mechanism here.

Instead, what I'd propose is this:

• the JSON returned by status.php should include the endpoint path for a new serverInfo endpoint (so clients supporting it can take advantage of that - and otherwise use older APIs)
• the JSON returned by the serverInfo endpoint would then include
  
  
  
  • capabilities: the same info that the current capabilities endpoint provides
  
  
  • endpoints: dictionary of endpoint paths mapped to endpoint names
  
  
  • user: the same info that the current user endpoint provides
  
  

Benefits of such an approach would include:

• it reduces the number of requests needed by the client upon connecting even compared to the status quo
• it provides a single source for all relevant information needed by clients to effectively communicate with the server

In summary: less requests, less overhead, more flexibility, better performance.

[butonic]

How about registering a .well-known? That would substitute not only the remote.php, but also the status.php.

[DeepDiver1975]

Therefore - while I think service discovery is a great feature for interoperability with software that's targeting open standards - I believe service discovery is not the right mechanism here.

I strongly disagree here - we want to target open standards. So this is the right mechanism.

~Just to clarify: using the wellknown endpoint causes no additional requests. The web server will rewrite the request - no redirect for the client to take care of.~

~The only additional scenario is the case where wellknown is not supported on the server. A fall back has to be used.~

[DeepDiver1975]

How about registering a .well-known? That would substitute not only the remote.php, but also the status.php.

I like this - let's do it

[butonic]

I would substitute the status.php with the .well-known request. that is the service discovery, as @felix-schwarz points out. Changing endpoints is the whole reason for having a .well-known, IMO.

@DeepDiver1975 While .well-known can be anything I would NOT make it a proxy. Clients should use it to check if an oc instance is present at a certain host (or maybe multiple) and how to interact with them: enpoints for sharing, endpoints for files, endpoint of the web ui, ... maybe endpoint of the IdP. https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig is a good example I think.

[DeepDiver1975]

I was wrong - it does redirect the client. Never the less - this is a request to be done only on account setup. During live operations no call to wellknown is necessary anymore.

https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig is a good example I think.

Actually I like that ....

[davigonz]

this is a request to be done only on account setup.

And save .wellknown somewhere to be used in the rest of operations?

In Android we save the baseUri (e.g. http://demo.owncloud.org) within an ownCloud client object during the account setup, so the .wellknown part could be appended in that moment as well. After that, completing the endpoint with webdav, ocs/v1, ocs/v2 or whatever depending on the performed operation would be enough if I'm not wrong.

[DeepDiver1975]

I'm closing this - not really of high prio