WebDAV Interop Report

On July 19th and 20th, there was a WebDAV interoperability event at UCSC, Santa Cruz. This was an engineering event targeted to find and improve the value of WebDAV for various products. There were nearly 60 people at the event, from 20 different organizations, representing 35 implementations of WebDAV, including 17 clients and 18 servers. Some brought both both the shipping and development versions of their products; counting these, there were 21 clients and 26 servers. These included several open source implementations.

Photos from the event are available at http://www.webdav.org/users/masinter/interop/photos.html.

See http://www.webdav.org/other/interop.html for the original event announcement.

The ground rules of the event were that individual results would not be reported, so this report only includes a summary.


Follow up

We exchanged contact information; groups will follow up with each other to retest as improvements get made. Having an event seems to have gotten everyone's attention.

Several RFC 2518 issues were raised; these should be raised on the main WebDAV list.

There a number of common implementation problems; if there are too many to include in the revision of RFC 2518; we should consider writing a separate "implementor's guide".

Most people were interested in participating in a virtual event in 1-2 months (say mid-September), where people set up servers and clients over the Internet, working with a phone conference. We will start the planning for this event now.

Event details

Almost all the participants had brought their software on laptop machines, as there wasn't building security. This made the set up and tear down quick.

People attending the event were assigned with an IP address for their machines. This IP address was used as an attendee number, which was automatically associated with a principal name/password pair that worked on all servers at the event. Server implementers were asked to create 100 principal/password pairs (some didn't).

There was no registration fee. The Internet Mail Consortium (www.imc.org) loaned us hubs & cables (thanks!). Xythos and Oracle donated lunch, and Adobe donated drinks & snacks. UCSC provided facilities and network connections, and Jim Whitehead and his students did the event planning and setup.

During the event, two of the laptops were infected with a worm/virus that was making its way around the net at the time--a server-based worm that infected web servers and, in turn, used them as a platform to mount additional attacks. The UCSC network staff noted an unusual traffic pattern from machines on the testing network The event included, in addition to WebDAV testing, free port scanning and a security check!

Who was there?

Groups present included the following:


Company Implementations
4D, Inc WebStar V
Adobe clients: GoLive 5.0, PhotoShop 6.0, Acrobat 5.0, 3 experimental, 1 test suite; 2 experimental servers
Apple OSX WebDAV FS (client)
CyberTeams WebSite Director
Endeavors MagiDAV (client & server)
HyperWave Hyperwave Information Server
IBM Almaden Research Center (experimental server)
Intraspect Intraspect 4
Merant PVCS Dimensions 7, PVCS Content Manager, DeltaV prototype
Microsoft Windows XP, Office XP, Exchange 2000, IIS 6.0, IIS 5.1
OpenText Livelink gateway
Oracle iFS, oradav, 9iR2
RiverFront WebDrive
Silverstream ePortal
South River Technologies WebIFS
TeamStream TeamDrive
VirtualEarth SimpleCMS
Xythos WebFile Server (2 versions)

Open Source

Tester Implementations
Keith Wannamaker mod_dav (Apache server module)
Joe Orton cadaver, sitecopy (clients)
Joe Feise DAV Explorer (client)
Remy Maucherat Jakarta Slide
Elias Sinderson SkunkDAV (client)
Sung Kim davfs (Linux file system driver)

Protocol issues

Here's a sample of the protocol issues discovered; these and others will be raised directly on the WebDAV list:

Implementation issues

Here is a sampling of implementation issues encountered, where it seems that the spec is clear but the implementations didn't do it as specified. Some of these might be ambiguities in the specification, or places where the spec should change (e.g., it's too hard to implement in some cases):