Lock the newly created file, get the lock token generated by the server and save it on a client.Verify if a file with such name exists.But to give you an idea of what WebDAV requests are being sent, below is a typical sequence of requests for average WebDAV client for file upload: The actual sequence of requests depends on the operation performed and varies between different WebDAV clients. The diagram below illustrates the whole process:
When the server receives the update request, it verifies that the lock token belongs to the item that is being updated and performs modifications. The WebDAV client application keeps the lock token and when it requires to perform any updates, it supplies the lock token with the request. The server generates the new lock token, marks the item as locked and returns the lock token to the client. When a WebDAV client requires to protect an item from modifications, that could be made by other users, it locks the item (usually file), submitting LOCK request to the server. The Class 3 is reported both for Class 1 and Class 2 server, regardless of ILock implementation. If you need to verify if your server reports Class 2 compliance, you can check the DAV header of OPTIONS request in your WebDAV server log or you can examine the traffic using HTTP debugging proxy (for example with Fiddler tool).Īs you can see the server also reports Class 3 compliance. It will also return LOCK and UNLOCK verbs in Allow and Public headers. After you implement ILockAsync interface on an item, the server will respond with DAV: 1, 2, 3 header, meaning the item supports locking. When discovering your WebDAV server compliance, WebDAV clients rely on DAV header returned with OPTIONS request that is usually sent to a folder item. How WebDAV Clients Discovers Class 2 Compliance Note that locking has nothing to do with authentication and authorization and does not protect from unauthorized access. When ILockAsync interface is implemented on a folder item your server will report a Class 2 compliance. To create a Class 2 server, you must implement ILockAsync interface on your folder and file items. If they discover a Class 1 server they will treat it as read-only.
Most WebDAV clients, such as Microsoft Miniredirector/Web Folders, Mac OS X Finder and Microsoft Office require Class 2 server.
MultistatusException - Errors have occured during processing of the subtree.In addition to features provided by Class 1 server, Class 2 server supports hierarchy items locking, that prevents concurrent modifications of items by several users. Throws: LockedException - The item is locked, so the method has been rejected. Returns: Actually applied lock (Server may modify timeout). owner - Provides information about the principal taking out a lock. timeout - Lock expiration time in seconds. deep - Indicates whether a lock is enforceable on the subtree. Parameters: shared - Indicates whether a lock is shared or exclusive. You must also associate generated token with the hierarchy item in your repository during this call.
In your Lock implementation you must generate lock token and create LockResult class instance.