Skip to content

spec: WebDAV Optimizations

Daniel Molkentin edited this page Jun 26, 2013 · 5 revisions

WebDAV optimizations

E-Tags

Introduction

The ownCloud clients use the WebDAV protocol (RFC 2518 et al) to access the files on the ownCloud Server, adding sync semantics on top.

When a sync run is performed, the clients need to know which files have changed. This can be achieved through time stamp comparison (dangerous due to clock skews on laptops and virtual servers) or changing hash sums (not an option due to ownClouds storage backend architecture, where some backends allow shared access and at the same time cannot provide hash sums on their own.

There are two naïve approaches to list the remote contents so the sync algorithm can judge what changed: Recursively iterating through all directories (called collections in WebDAV lingo) on the server via PROPFIND (slow due to roundtrips), or performing a single recursive PROPFIND with infinite depth (resulting in a potentially huge amount of data on every check).

Optimizations of Client Sync Operations

The ownCloud clients store the server filesystem layout in a local cache, and hence would only be interested in the difference between two consecutive sync runs, which leads to potential for optimization, which is exploited as follows:

Since ownCloud 5, an E-Tag property is provided by the server for every folder and file as part of its PROPFIND response, as proposed in RFC4918. As soon as a file changes, the file is assigned a new E-Tag. Likewise, it's folder receives a new E-Tag, as does its parent, etc. This way, the client traffic is reduced to a single HEAD or PROPFIND request in case nothing changes.

If something changes, the relevant changes can be quickly evaluated with a few PROPFINDs for those directories where the E-Tag has changed.

Case consideration for Client-Operations affecting E-Tags

  • Server has new file or directory: E-Tag gets assigned, E-Tags of parent directories are modified up until the root directory
  • File on server gets deleted: File is deleted, E-Tag of parent directories is modified recursively.
  • File has new file or directory: New entry in client DB is created, without the E-Tag. Once a file has been uploaded to the server via PUT, a PROPFIND is issued to retrieve the E-Tag value and entered into the local sync database (Possible optimization: E-Tag is returned in response to the PUT request (?)).

Server and Backend Implementation Details

...

Limitations

...