Open Radar

 
Summary:

WebDAV defines an HTTP response code, 207, for returning multiple error codes for a single request. The MacOSX webdav client implementation interprets response 207 as success, even if the error codes it contains indicate failure.

Steps to Reproduce:

Presumably there are many ways to do this, but here's a simple way:

1. Set up an apache2 server with mod_dav (e.g., use the server that ships with OSX)
2. Create a small directory hierarchy on the DAV server, perhaps a/b/c, so that you can mount 'a' in the Finder
3. Issue a LOCK request against a/b by hand (e.g., using curl)
4. Mount 'a' in the finder
5. Attempt to create files in 'a' or in 'a/b'

Expected Results:

Webdavfs should notice that DAV operations are failing and respond accordingly (e.g. translating them to EBUSY or EACCESS or something).

Actual Results:

Webdavfs misinterprets failure indications as success, leading to file creation silently failing. "echo blah > foo" "succeeds", but 'foo' does not exist afterwards.

Webdavfs emits the following error text to the console, which is also indirectly indicative of the bug:

26 Jul 10 5:23:41 PM	webdavfs_agent[18526]	error parsing lock token; file: /SourceCache/webdavfs/webdavfs-293/mount.tproj/webdav_parse.c; line: 1744

Notes:

The multistatus response occurs because lock contention results in two errors from Apache: one for the actual resource in the request, and one indicating the resource on which the lock was placed (for a lock with Depth: inifinity these can be different resources).

If you look at the source code to webdavfs-293 from opensource.apple.com, the error is pretty straightforward. In translate_status_to_error() in webdav_network.c, all error codes starting with '2' are interpreted as an unquallified success, which is wrong. In order to conform to the DAV spec, error code 207 needs to be interpreted with more care. For instructions, see RFC 4918 sections 11.1 and 13.