10 Jan 2006

We need a webdav:// URL scheme!

When browsing a remote filesystem, it's more convenient to use a filesystem browser UI rather than an HTML directory listing. Unfortunately, if the protocol used is WebDAV, there's no way to effect a switchover from a HTML UI. This is because URLs that point to WebDAV shares use the same http scheme and are therefore indistinguishable from HTTP URLs. Neither can you follow the URL to see what's on the other side (in fact, the method (pun intended) of following the URL is itself different based on whether you want to use the WebDAV protocol; you do a PROPFIND instead of a GET). So if a particular resource has to be opened as a WebDAV resource, the browser must be explicitly told.

To this end, the IETF wants to introduce a new MIME type, application/davmount+xml, that instructs the web browser to open a (specified) resource in a WebDAV filesystem browser. So a webpage that wants to link to a WebDAV resource must link to this mount request document which in turn specifies the location of the resource.

The alternative is to use a webdav:// URL.

Here are the problems I see with the proposed spec:
  1. Webmasters must create these mount request documents, and every point in the WebDAV filesystem hierarchy needs its own mount request files. So the webmasters may have to create a lot of these files used just for redirection. Or dynamically generate them. Neither is appropriate for a task that can be done using something as simple as a URL with a different scheme.
  2. A new scheme would be useful when a user types a URL into a client program. Presently, clients use ad hoc solutions. For instance, Internet Explorer's Open box has an Open as Web Folder option that you must check to use WebDAV. A webdav:// URL would be more straightforward.
  3. The proposed spec requires another round-trip to the server.
You can use a data URI (thanks Julian Reschke for pointing this out) and that will handle problems 1 and 3. But it will still be unwieldy; would you prefer a URL that encodes:

Content-Type: application/davmount+xml

<dm:mount xmlns:dm="http://purl.org/NET/webdav/mount">

or this:

True, you don't need a new scheme, but that doesn't mean you shouldn't have one, given that the alternative suffers from the above problems. WebDAV is a different protocol from "plain" HTTP (it introduces new HTTP methods), and if we don't use URL schemes to identify protocols, what are the schemes there for? Why needlessly complicate things?

Nautilus did the right thing and went for a dav:// scheme. Konqueror uses webdav://

Last Updated: 12 Feb 2006


  1. You must understand that webdav:// is just an interface. Internally, it'd have to follow the protocol specs. You are comparing an interface to the protocol, which is incorrect.

  2. Yes, I understand the difference between a protocol and an interface. I was saying it would be very helpful to have a different interface, if you will, to tell the browser to use the WebDAV protocol. Just as typing ftp:// into a browser tells it use the FTP protocol

  3. Julian Reschke11:24 pm


    First of all, why didn't you send the feedback to either the WebDAV WG mailing list or the author? Both addresses are in the document.

    Then: URI schemes are for identifying resources, not for invoking functions. Just because others do it (KDE webdav, Apple ical, itms) doesn't make it the right approach. If you think that's the proper way to do it, try to get it published by the IETF or the W3C. (good luck).

    Defining a MIME type IMHO was the right thing to do; it integrates way better into existing user agents, and is portable.

    I fail to see why one roundtrip to retrieve the mount message is a problem. But if you really feel it is, just store it in a "data" URI inside the HTML.

    Cheers, Julian

  4. Thanks Julian for your comments. I think I'll soon post this on the WebDAV WG list.

    > URI schemes are for identifying resources,
    > not for invoking functions
    I'm not sure what you mean by invoking functions, but aren't URI schemes meant to identify protocols? I understand that we should avoid defining new schemes when existing ones can work, but the proposed spec is much more complex than a URL, especially for webmasters who need to create these davmount requests. Why not make things simpler?

    > Defining a MIME type IMHO was the right thing to do;
    > it integrates way better into existing user agents,
    > and is portable.
    By this if you mean that it's easier and more portable to create a browser plug-in for a new MIME type than for a new URI scheme, I think it's the right tradeoff to make slightly more work for the tool makers to simplify things for web authors.

    Thanks for the info on data URIs; I didn't know about them.

  5. Julian Reschke5:17 pm


    WebDAV is HTTP. It isn't a different protocol, so it should use the same URI scheme.

    And no, you don't need to create a browser plugin for a MIME type. Just register an application responsible for that MIME type in your operating system. The user agents do use that (that's true at least for Firefox and Internet Explorer).

    Best regards, Julian

  6. Julian,
    I'm sure you'll agree that WebDAV is not just HTTP but an extension of it; the exchange between the client and the server is dependent on whether WebDAV is being used (in which case the client does a PROPFIND rather than a GET). Since the client needs to be told which protocol to use (plain HTTP or WebDAV), I think a URI scheme is the perfect solution. What else are URI schemes for?

    My main concern is that the davmount documents seem to be much more complex for web authors to work with than a URL. Yes, this will require changes in the web browser to support this dispatch, but I think the tradeoff is worth it.

    Another thought: have the WebDAV servers set a header (in reply to a GET) that says this is a webdav server. Then a WebDAV-aware browser agent will be able to automatically switch over to a tree view, and clients that don't support WebDAV will ignore the header and work as before. This way, if a WebDAV resource is accessed using plain HTTP rather than WebDAV (more precisely, by a GET rather than a PROPFIND), it will be possible to automatically disptach to a WebDAV browser (if the web browser chooses to). I think a client should be able to determine from the response whether it's talking to a WebDAV server.

    Am I missing anything here?
    I'm looking forward to your comments.

  7. Julian Reschke1:46 am


    yes, it's an extension, but it's still HTTP.

    Is GET to a WebDAV server an HTTP or a WebDAV request? See.

    If you think that an approach that requires changes in existing user agents has any chance of adoption, please try. I mean, do you seriously expect Microsoft to add this into IE?

    Anyway, I think this should be discussed on the mailing list -- that's what it is for -- not on a Blog :-).

    Best regards, Julian

  8. I'd like to see a little checkbox near the URL in my browser to enable webdav. Basically it would say, try a PROPFIND first, if you get a Collection display it like a folder, else fall-back to GET. Webdav are just some new methos which make sense on a subset of http-resources, the resources are the same and I'd like to have the same URL usable in my browser, in openoffice, etc.
    I don't see why the same resource (say an image) can be accessed both with an http and a webdav-url.

  9. Asking the user to tick a checkbox to use WebDAV doesn't help when a webpage wants to open a WebDAV share in a filesystem browser. For instance, IE switches to a filesystem view when it's given a FTP URL; this would not be possible for WebDAV. I can see the logic with not wanting two URLs to refer to the same resource. I think the best solution is to have WebDAV servers return a special HTTP response header that tells a WebDAV-aware browser that it can switch over to a file browser UI (or run a separate tool for this).

  10. The header indicating that the requested resource can be accessed with propfind doesn't solve the problem when a webpage link wants to suggest that the target should be opened as a filesystem like directory view. But I guess this should be done with client-side scripting rather than an URL scheme, it is similar to telling the browser to open a link-target in a specific frame or in a new window.