WebDAV is an extension to HTTP, and it is growing more and more popular as a standard for file sharing. Today’s operating systems are becoming extremely web-aware, and many now have built-in support for mounting “shares” exported by WebDAV servers.
This excerpt is from Version Control with Subversion. Written by members of the development that maintains Subversion, this is the official guide and reference manual for the popular open source revision control technology. The new edition covers Subversion 1.5 and includes an introduction to Subversion, a guided tour of the capabilities and structure, detailed coverage of advanced topics, such as branching and repository administration, and best practice recommendations.
If you use Apache as your Subversion network server, to some extent you are also running a WebDAV server. This appendix provides some background on the nature of this protocol, how Subversion uses it, and how well Subversion interoperates with other software that is WebDAV-aware.
DAV stands for “Distributed Authoring and Versioning.” RFC 2518 defines a set of concepts and accompanying extension methods to HTTP 1.1 that make the Web a more universal read/write medium. The basic idea is that a WebDAV-compliant web server can act like a generic file server; clients can “mount” shared folders over HTTP that behave much like other network filesystems (such as NFS or SMB).
The tragedy, though, is that despite the acronym, the RFC specification doesn’t actually describe any sort of version control. Basic WebDAV clients and servers assume that only one version of each file or directory exists and that it can be repeatedly overwritten.
Because RFC 2518 left out versioning concepts, another committee was stuck with the responsibility of writing RFC 3253 a few years later. The new RFC adds versioning concepts to WebDAV, placing the “V” back in “DAV”—hence the term “DeltaV.” WebDAV/DeltaV clients and servers are often called just “DeltaV” programs, since DeltaV implies the existence of basic WebDAV.
The original WebDAV standard has been widely successful. Every modern computer operating system has a general WebDAV client built in (details to follow), and a number of popular standalone applications are also able to speak WebDAV—Microsoft Office, Dreamweaver, and Photoshop, to name a few. On the server end, Apache HTTP Server has been able to provide WebDAV services since 1998 and is considered the de facto open source standard. Several other commercial WebDAV servers are available, including Microsoft’s own IIS.
DeltaV, unfortunately, has not been so successful. It’s very difficult to find any DeltaV clients or servers. The few that do exist are relatively unknown commercial products, and thus it’s very difficult to test interoperability. It’s not entirely clear why DeltaV has remained stagnant. Some opine that the specification is just too complex. Others argue that while WebDAV’s features have mass appeal (even the least technical users appreciate network file sharing), its version control features just aren’t interesting or necessary for most users. Finally, some believe that DeltaV remains unpopular because there’s still no open source server product that implements it well.
When Subversion was still in its design phase, it seemed like a great idea to use Apache as a network server. It already had a module to provide WebDAV services. DeltaV was a relatively new specification. The hope was that the Subversion server module (mod_dav_svn) would eventually evolve into an open source DeltaV reference implementation. Unfortunately, DeltaV has a very specific versioning model that doesn’t quite line up with Subversion’s model. Some concepts were mappable; others were not.
What does this mean, then?
First, the Subversion client is not a fully implemented DeltaV
client. It needs certain types of things from the server that DeltaV
itself cannot provide, and thus it is largely dependent on a number of
requests that only mod_dav_svn
Second, mod_dav_svn is not a fully realized DeltaV server. Many portions of the DeltaV specification were irrelevant to Subversion and were thus left unimplemented.
There is still some debate in the developer community as to whether it’s worthwhile to remedy either of these situations. It’s fairly unrealistic to change Subversion’s design to match DeltaV, so there’s probably no way the client can ever learn to get everything it needs from a general DeltaV server. On the other hand, mod_dav_svn could be further developed to implement all of DeltaV, but it’s hard to find motivation to do so—there are almost no DeltaV clients to interoperate with.
Although the Subversion client is not a full DeltaV client, and the Subversion server is not a full DeltaV server, there’s still a glimmer of WebDAV interoperability to be happy about: autoversioning.
Autoversioning is an optional feature defined in the DeltaV
standard. A typical DeltaV server will reject an ignorant WebDAV client
attempting to do a
PUT to a file that’s
under version control. To change a version-controlled file, the server
expects a series of proper versioning requests: something like
But if the DeltaV server supports autoversioning, write requests from
basic WebDAV clients are accepted. The server behaves as though the client
had issued the proper series of versioning requests,
performing a commit under the hood. In other words, it allows a DeltaV
server to interoperate with ordinary WebDAV clients that don’t understand
Because so many operating systems have already integrated WebDAV clients, the use case for this feature can be incredibly appealing to administrators working with nontechnical users. Imagine an office of ordinary users running Microsoft Windows or Mac OS. Each user “mounts” the Subversion repository, which appears to be an ordinary network folder. They use the shared folder as they always do: open files, edit them, and save them. Meanwhile, the server is automatically versioning everything. Any administrator (or knowledgeable user) can still use a Subversion client to search history and retrieve older versions of data.
This scenario isn’t fiction—it’s real and it works, as of Subversion
1.2 and later. To activate autoversioning in mod_dav_svn, use the
directive within the
Location block, like so:
<Location /repos> DAV svn SVNPath /var/svn/repository SVNAutoversioning on </Location>
When Subversion autoversioning is active, write requests from WebDAV clients result in automatic commits. A generic log message is automatically generated and attached to each revision.
Before activating this feature, however, understand what you’re
getting into. WebDAV clients tend to do many write
requests, resulting in a huge number of automatically committed revisions.
For example, when saving data, many clients will do a
PUT of a 0-byte file (as a way of reserving a name),
followed by another
PUT with the real
file data. The single file-write results in two separate commits. Also
consider that many applications autosave every few minutes, resulting in
even more commits.
If you have a
post-commit hook program that sends
email, you may want to disable email generation either altogether or on
certain sections of the repository; it depends on whether you think the
influx of emails will still prove to be valuable notifications. Also, a
post-commit hook program can distinguish between
a transaction created via autoversioning and one created through a normal
Subversion commit operation. The
trick is to look for a revision property named
svn:autoversioned. If present, the commit was
made by a generic WebDAV client.
Another feature that may be a useful complement for Subversion’s
autoversioning comes from Apache’s
mod_mime module. If a WebDAV client adds a new file to the repository, there’s
no opportunity for the user to set the
svn:mime-type property. This might cause the
file to appear as a generic icon when viewed within a WebDAV shared
folder, not having an association with any application. One remedy is to
have a sysadmin (or other
Subversion-knowledgeable person) check out a working copy and manually set
svn:mime-type property on necessary
files. But there’s potentially no end to such cleanup tasks. Instead, you
can use the
directive in your Subversion
<Location /repos> DAV svn SVNPath /var/svn/repository SVNAutoversioning on ModMimeUsePathInfo on </Location>
This directive allows
attempt automatic deduction of the MIME type on new files that enter the
repository via autoversioning. The module looks at the file’s named
extension and possibly the contents as well; if the file matches some
common patterns, the file’s
svn:mime-type property will be set
All WebDAV clients fall into one of three categories: standalone applications, file-explorer extensions, or filesystem implementations. These categories broadly define the types of WebDAV functionality available to users. Table C.1, “Common WebDAV clients” gives our categorization as well as a quick description of some common pieces of WebDAV-enabled software. You can find more details about these software offerings, as well as their general category, in the sections that follow.
Table C.1. Common WebDAV clients
|Adobe Photoshop||Standalone WebDAV application||X||Image editing software, allowing direct opening from and writing to WebDAV URLs|
|cadaver||Standalone WebDAV application||X||X||Command-line WebDAV client supporting file transfer, tree, and locking operations|
|DAV Explorer||Standalone WebDAV application||X||X||X||Java GUI tool for exploring WebDAV shares|
|Adobe Dreamweaver||Standalone WebDAV application||X||Web production software able to directly read from and write to WebDAV URLs|
|Microsoft Office||Standalone WebDAV application||X||Office productivity suite with several components able to directly read from and write to WebDAV URLs|
|Microsoft Web Folders||File-explorer WebDAV extension||X||GUI file-explorer program able to perform tree operations on a WebDAV share|
|GNOME Nautilus||File-explorer WebDAV extension||X||GUI file explorer able to perform tree operations on a WebDAV share|
|KDE Konqueror||File-explorer WebDAV extension||X||GUI file explorer able to perform tree operations on a WebDAV share|
|Mac OS X||WebDAV filesystem implementation||X||Operating system that has built-in support for mounting WebDAV shares|
|Novell NetDrive||WebDAV filesystem implementation||X||Drive-mapping program for assigning Windows drive letters to a mounted remote WebDAV share|
|SRT WebDrive||WebDAV filesystem implementation||X||File transfer software, which, among other things, allows the assignment of Windows drive letters to a mounted remote WebDAV share|
|davfs2||WebDAV filesystem implementation||X||Linux filesystem driver that allows you to mount a WebDAV share|
On Windows, several well-known applications contain integrated WebDAV client functionality, such as Microsoft’s Office, Adobe’s Photoshop and Dreamweaver programs. They’re able to directly open and save to URLs, and tend to make heavy use of WebDAV locks when editing a file.
Note that while many of these programs also exist for Mac OS X, they do not appear to support WebDAV directly on that platform. In fact, on Mac OS X, the dialog box doesn’t allow one to type a path or URL at all. It’s likely that the WebDAV features were deliberately left out of Macintosh versions of these programs, since OS X already provides such excellent low-level filesystem support for WebDAV.
cadaver is a bare-bones Unix command-line program for browsing and changing WebDAV shares. Like the Subversion client, it uses the neon HTTP library—not surprisingly, since both neon and cadaver are written by the same author. cadaver is free software (GPL license) and is available at http://www.webdav.org/cadaver/.
Using cadaver is similar to using a command-line FTP program, and thus it’s extremely useful for basic WebDAV debugging. It can be used to upload or download files in a pinch, to examine properties, and to copy, move, lock, or unlock files:
$ cadaver http://host/repos dav:/repos/> ls Listing collection '/repos/': succeeded. Coll: > foobar 0 May 10 16:19 > playwright.el 2864 May 4 16:18 > proofbypoem.txt 1461 May 5 15:09 > westcoast.jpg 66737 May 5 15:09 dav:/repos/> put README Uploading README to '/repos/README': Progress: [=============================>] 100.0% of 357 bytes succeeded. dav:/repos/> get proofbypoem.txt Downloading '/repos/proofbypoem.txt' to proofbypoem.txt: Progress: [=============================>] 100.0% of 1461 bytes succeeded.
DAV Explorer is another standalone WebDAV client, written in Java. It’s under a free Apache-like license and is available at http://www.ics.uci.edu/~webdav/. It does everything cadaver does but has the advantages of being portable and being a more user-friendly GUI application. It’s also one of the first clients to support the new WebDAV Access Control Protocol (RFC 3744).
Of course, DAV Explorer’s ACL support is useless in this case,
since mod_dav_svn doesn’t support
it. The fact that both cadaver and DAV Explorer support some limited
DeltaV commands isn’t particularly useful either, since they don’t
MKACTIVITY requests. But it’s
not relevant anyway; we’re assuming all of these clients are operating
against an autoversioning repository.
Some popular file explorer GUI programs support WebDAV extensions that allow a user to browse a DAV share as though it was just another directory on the local computer and to perform basic tree editing operations on the items in that share. For example, Windows Explorer is able to browse a WebDAV server as a “network place.” Users can drag files to and from the desktop, or can rename, copy, or delete files in the usual way. But because it’s only a feature of the file explorer, the DAV share isn’t visible to ordinary applications. All DAV interaction must happen through the explorer interface.
Microsoft was one of the original backers of the WebDAV specification and first started shipping a client in Windows 98, which was known as Web Folders. This client was also shipped in Windows NT 4.0 and Windows 2000.
The original Web Folders client was an extension to Explorer, the main GUI program used to browse filesystems. It works well enough. In Windows 98, the feature might need to be explicitly installed if Web Folders aren’t already visible inside My Computer. In Windows 2000, simply add a new “network place,” enter the URL, and the WebDAV share will pop up for browsing.
With the release of Windows XP, Microsoft started shipping a new
implementation of Web Folders, known as the WebDAV Mini-Redirector.
The new implementation is a filesystem-level client, allowing WebDAV
shares to be mounted as drive letters. Unfortunately, this
implementation is incredibly buggy. The client usually tries to
convert HTTP URLs (
http://host/repos) into Universal Naming
Convention (UNC) share notation
\\host\repos); it also often tries to
use Windows Domain authentication to respond to basic-auth HTTP
challenges, sending usernames as
HOST\username. These interoperability
problems are severe and are documented in numerous places around the
Web, to the frustration of many users. Even Greg Stein, the original
author of Apache’s WebDAV module, bluntly states that XP Web Folders
simply can’t operate against an Apache server.
Windows Vista’s initial implementation of Web Folders seems to be almost the same as XP’s, so it has the same sort of problems. With luck, Microsoft will remedy these issues in a Vista Service Pack.
However, there seem to be workarounds for both XP and Vista that allow Web Folders to work against Apache. Users have mostly reported success with these techniques, so we’ll relay them here.
On Windows XP, you have two options. First, search Microsoft’s web site
for update KB90730, “Software Update for Web Folders.”
This may fix all your problems. If it doesn’t, it seems that the
original pre-XP Web Folders implementation is still buried within the
system. You can unearth it by going to Network Places and adding a new
network place. When prompted, enter the URL of the repository, but
include a port number in the URL. For example,
you should enter
http://host:80/repos instead. Respond to any
authentication prompts with your Subversion credentials.
On Windows Vista, the same KB90730 update may clear everything
up. But there may still be other issues. Some users have reported that
Vista considers all
connections insecure, and thus will always fail any authentication
challenges from Apache unless the connection happens over
https://. If you’re unable to connect to the
Subversion repository via SSL, you can tweak the system registry to
turn off this behavior. Just change the value of the
2. A final
warning: be sure to set up the Web Folder to point to the repository’s
root directory (
/), rather than
some subdirectory such as
Vista Web Folders seems to work only against repository roots.
In general, while these workarounds may function for you, you might get a better overall experience using a third-party WebDAV client such as WebDrive or NetDrive.
Nautilus is the official file manager/browser for the GNOME desktop (http://www.gnome.org), and Konqueror is the manager/browser for the KDE desktop (http://www.kde.org). Both of these applications have an explorer-level WebDAV client built-in, and they operate just fine against an autoversioning repository.
In GNOME’s Nautilus, select themenu item and enter the URL in the dialog box presented. The repository should then be displayed like any other filesystem.
In KDE’s Konqueror, you need to use the
webdav:// scheme when entering the URL in
the location bar. If you enter an
http:// URL, Konqueror will behave like an
ordinary web browser. You’ll likely see the generic HTML directory
listing produced by mod_dav_svn.
When you enter
webdav://host/repos instead of
http://host/repos, Konqueror becomes a WebDAV
client and displays the repository as a filesystem.
The WebDAV filesystem implementation is arguably the best sort of WebDAV client. It’s implemented as a low-level filesystem module, typically within the operating system’s kernel. This means that the DAV share is mounted like any other network filesystem, similar to mounting an NFS share on Unix or attaching an SMB share as a drive letter in Windows. As a result, this sort of client provides completely transparent read/write WebDAV access to all programs. Applications aren’t even aware that WebDAV requests are happening.
Both WebDrive and NetDrive are excellent commercial products that allow a WebDAV share to be attached as drive letters in Windows. As a result, you can operate on the contents of these WebDAV-backed pseudodrives as easily as you can against real local hard drives, and in the same ways. You can purchase WebDrive from South River Technologies (http://www.southrivertech.com). Novell’s NetDrive is freely available online, but it requires users to have a NetWare license.
Apple’s OS X operating system has an integrated filesystem-level WebDAV
client. From the Finder, select the menu item. Enter a
WebDAV URL, and it appears as a disk on the desktop, just like any
other mounted volume. You can also mount a WebDAV share from the
Darwin terminal by using the
filesystem type with the mount
$ mount -t webdav http://svn.example.com/repos/project /some/mountpoint $
Note that if your mod_dav_svn is older than version 1.2, OS X will refuse to mount the share as read/write; it will appear as read-only. This is because OS X insists on locking support for read/write shares, and the ability to lock files first appeared in Subversion 1.2.
Also, OS X’s WebDAV client can sometimes be overly sensitive to
HTTP redirects. If OS X is unable to mount the repository at all, you
may need to enable the
BrowserMatch directive in the Apache
BrowserMatch "^WebDAVFS/1." redirect-carefully
Linux davfs2 is a filesystem module for the Linux kernel, whose development is organized at http://dav.sourceforge.net/. Once you install davfs2, you can mount a WebDAV network share using the usual Linux mount command:
$ mount.davfs http://host/repos /mnt/dav
 WebDAV support was removed from Microsoft Access for some reason, but it exists in the rest of the Office suite.
If you enjoyed this excerpt, buy a copy of Version Control with Subversion.
Copyright © 2009 O'Reilly Media, Inc.