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.

Results

• Lots got tested: perhaps 200 of the 546 client vs. server pairs were reported as tested.
• Not much worked: very few of the pairs reported a "worked perfectly" score! Many pairs couldn't connect at all (e.g., because of authentication issues) or couldn't do updates (e.g., because of issues with locking, authentication, etc.). The plans to do detailed analysis of WebDAV operations didn't get far.
• Things got better: many of the implementors managed to make patches or software revisions to their implementations to improve interoperability.
• Success: Everyone agreed that the event was very valuable and that we should do it again soon.

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:

Commercial

Open Source

Protocol issues

• Can a server rewrite the 'lockowner' string from what the client originally sent?
• Clarification of HTTP vs. XML dates in WebDAV spec
• Clarification of proper encoding of resource display names in URLs, using UTF8, folder names with spaces
• issues about the "source" property: not really used, a different header is
• presenting many lock tokens when required for a request: how should htis be done?
• cacheing of PROPFIND results: is it allowed?
• What should a server send if it is asked for a build-in DAV property which is not set on the server (e. g. the lockdiscovery property for a non locked resource). Should the server send an empty property (e. g. <D:lockdiscovery/>) like mod_dav does, should the server send an empty prop element (<D:prop/>) like IIS does or is the server even allowed to send a "404 Not Found" like a lot of servers did?

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):

• clients attempting to query the "root" of the WebDAV namespace; e.g., for resource http://server/foo/bar, the client did "OPTIONS  / HTTP/ 1.1" and required that to succeed; then "PROPFIND /foo HTTP/1.1" and also required that to succeed
• Server ignoring the credentials of a second HTTP request on the same connection and assuming the credentials of the first request (HTTP specifies no relationship between "Authorization" headers of multiple requests on same connection.)
• Clients reacting badly to erroneous server behavior (tradeoff between giving users annoying messages vs. not ever detecting bad servers)
• Servers (or clients) relying on url/filename extension rather than MIME type
• Using cookies in order to optimize server performance; if this is legal, clients should expect it
• What errors should a client expect from PROPFIND? 404 Not Found?
• Servers must implement PROPPATCH to support some clients/workflows
• Many servers didn't support locking, and some clients required locking
• problems with lock null
• issues with implementation of folder locking (many didn't)
• issues with implementations of shared locking (many didn't)
• PROPPATCH of non-flat properties (many didn't)
• issues with implementations of PUT
• issues with client or server and folder URLs that do not have a trailing "/"
• Digest Authentication is really mandatory to implement, and some servers will require it soon
• Multiple WWW-Authenticate headers, including 'negotiate'