finder
Open finder
Open the 'Go' menu and press Connect to Server (or press Apple-G)
Fill in the full url to the webdav server, and hit connect
The Finder client is a pretty solid one, but the client forces itself into read-only mode if the Dav server only supports Class 1 (Class 2 has locking support)
Finder uses Transfer-Encoding: Chunked in PUT request bodies. This is a little used HTTP feature, and therefore not implemented in a bunch of webservers. The only server I've seen so far that handles this reasonably well is jsDAV stand-alone, NodeJS with a mounted jsDAV share and Apache. Nginx and Lighttpd respond with 411 Length Required, which is completely ignored by Finder. This was seen on nginx 0.7.63.
Finder will throw an error if an attempt is made to create or copy softlinks.
The biggest problem with Finder and OS/X in general is the messiness it leaves behind and the unneeded amount of requests.. Here's a list of requests Finder makes after mounting the share
OPTIONS [baseurl] - First it checks, as it should if this is a valid WebDAV server
PROPFIND [baseurl] - Properties of root path
PROPFIND [baseurl] - Exact same query, except now its asking for quota information (could have been merged with step #2)
PROPFIND [baseurl] - Exact same as request #2
PROPFIND [baseurl] - Another one, exact same
PROPFIND [baseurl] - Same thing
PROPFIND [baseurl] - You guessed it
PROPFIND [baseurl] - sigh..
PROPFIND [baseurl]/mach_kernel - Its looking for the kernel image, not sure why..
PROPFIND [baseurl]/.Spotlight-V100 - Looking for spotlight configuration
PROPFIND [baseurl]/._. - OS/X stores resource data in a file of the format ._filename This file is used to store additional meta-data for filesystem that don't support this. It's really annoyhing and OS/X does it on windows shares too
PROPFIND [baseurl]/Backups.backupdb - Backup configuration
PROPFIND [baseurl]/._. - Exact same thing as before
PROPFIND [baseurl]/.metadata_never_index - haven't looked up what this means
PROPFIND [baseurl]/Backups.backupdb - Same as before
PROPFIND [baseurl]/Backups.backupdb - OS/X tries it twice, just to be sure
PROPFIND [baseurl]/._. - Redundant again
PROPFIND [baseurl]/._. - Redundant
PROPFIND [baseurl]/.metadata_never_index - Redundant
PROPFIND [baseurl] - Redundant
PROPFIND [baseurl]/Contents - Not sure what this file means
PROPFIND [baseurl]/Contents - redundant
PROPFIND [baseurl]/Contents` - redundant
PROPFIND [baseurl]/Contents - redundant
PROPFIND [baseurl]/Contents - redundant
PROPFIND [baseurl]/Contents - redundant
PROPFIND [baseurl]/._. - Redundant
PROPFIND [baseurl]/._. - Redundant
PROPFIND [baseurl]/Contents - redundant
PROPFIND [baseurl]/mach_kernel - redundant
PROPFIND [baseurl]/Contents - redundant
PROPFIND [baseurl]/Backups.backupdb - redundant
PROPFIND [baseurl]/._. - Redundant
PROPFIND [baseurl]/Contents - redundant
PROPFIND [baseurl]/Contents - redundant
PROPFIND [baseurl]/._. - Redundant
PROPFIND [baseurl]/Contents - redundant
PROPFIND [baseurl]/._. - Redundant
PROPFIND [baseurl]/.DS_Store - Finder stores things like the background and other directory-specific settings
PROPFIND [baseurl]/Contents - redundant
PROPFIND [baseurl]/mach_kernel - redundant
PROPFIND [baseurl]/._. - Redundant
PROPFIND [baseurl]/._. - Redundant
PROPFIND [baseurl]/._. - Redundant
PROPFIND [baseurl]/._. - Redundant
PROPFIND [baseurl]/Backups.backupdb - redundant
PROPFIND [baseurl]/Contents - redundant
PROPFIND [baseurl]/Contents - redundant
PROPFIND [baseurl]/Contents - redundant
PROPFIND [baseurl]/Contents - redundant
PROPFIND [baseurl] - Redundant
PROPFIND [baseurl] - Redundant
And lastly it downloads every single file in the folder, regardless of the size..
So, as a result of all this. Finder is among the slowest of WebDAV clients.. A lot of these should be easily fixable, as they're just redundant requests..
Resource-fork request seem to most common, and sometimes Finder can even go into a loop trying to request the fork every x seconds. This can be migitated by always sending back a valid resource fork.
A small optimization you can make on the client side is to disable creation of .DS_Store files. Run the following from a terminal to achieve this:
defaults write com.apple.desktopservices DSDontWriteNetworkStores true
Note however that this will disable .DS_Store for all network drives, not just your WebDAV drives.
Finder luckily has good support for the Content-Range header. This will reduce the actual size of the requires bodies quite well.
Seen User-agents:
- WebDAVFS/1.5 (01508000) Darwin/9.2.2 (i386)
- WebDAVFS/1.7 (01708000) Darwin/9.4.0 (i386)
- WebDAVFS/1.7 (01708000) Darwin/9.6.0 (i386)
Finder requires all files to have the Content-Length header, without it, you'll get really strange results
For files and directories, Finder will request the following properties:
- getlastmodified
- getcontentlength
- resourceType
Rarely it will also ask for appledoubleheader, defined in the http://www.apple.com/webdav_fs/props/ namespace. This seems to be an alternative way to request the resource forks, but Finder doesn't follow its own standard and still requests for ._filename-type requests. You can freely ignore this.
Initially, Finder will make a seperate request to retrieve the quota information, using the following properties:
- quota-available-bytes
- quota-used-bytes
- quota
- quotaused
So far I haven't been able to figure out where 'quota' and 'quotaused' are defined, and what they should contain. Just using the standard quota-available-bytes and quota-used-bytes from rfc4331 works, however.
Finder does not deal well with timezones, and treat every time from getlastmodified as UTC. Therefore it's best to send back all getlastmodified properties in the UTC timezone.
Basic authentication and digest authentication work quite well.
OS/X Finder uses UTF-8 to encode non-latin characters. The encoding it uses for characters such as the u-umlaut is u%CC%88 (a lowercase u + unicode codepoint U+0308).
A more common encoding is %C3%BC (U+00FC), which is a single codepoint for the u-umlaut, instead of the combination.
Currently jsDAV does not normalize, but it might in the future if there's sufficient interest.
Based on the original document at http://code.google.com/p/sabredav/wiki/Finder