RFC 4709

Mounting Web Distributed Authoring and Versioning (WebDAV) Servers

πŸ“… published October 2006, from ietf

Mounting Web Distributed Authoring and Versioning (WebDAV) Servers πŸŽ€

Okay bestie, this is RFC 4709 πŸ’– It was written by J. Reschke from greenbytes and dated October 2006. It's an Informational doc, which means it shares info with the Internet community and is not a standard 🌸 The title block doesn't list any RFCs it obsoletes or updates, so it's a solo queen πŸ‘‘

Quick note: the Abstract says "Web Distinguished Authoring and Versioning." The acronym is WebDAV, which stands for "Distributed," so that's probably a typo in the original πŸ™ˆ

Status of This Memo ✨

This memo gives info to the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited πŸ¦‹

Copyright (C) The Internet Society (2006).

Abstract 🌈

Right now there's no uniform way for a web browser to handle a link that opens an editable view of a WebDAV server. Like, it would be so useful to click a link and land in a window where you can drag and drop stuff onto a WebDAV server's resources πŸ“

This document defines a mechanism and a document format that lets WebDAV servers send "mounting" info to a WebDAV client 🧚 The whole thing is designed to work on any platform and with any combo of browser and WebDAV client. It relies only on the well-understood dispatch of documents by their MIME type, so no fancy new tech needed πŸ’œ

Table of Contents πŸ“‹

   1. Introduction ....................................................2
   2. Terminology .....................................................3
   3. Format ..........................................................3
      3.1. dm:mount ...................................................4
      3.2. dm:url .....................................................4
      3.3. dm:open ....................................................4
      3.4. dm:username ................................................4
   4. Example .........................................................4
   5. Internationalization Considerations .............................5
   6. IANA Considerations .............................................6
      6.1. MIME Type Registration .....................................6
   7. Security Considerations .........................................8
   8. Acknowledgements ................................................8
   9. References ......................................................9
      9.1. Normative References .......................................9
      9.2. Informative References .....................................9
   Appendix A.  Alternative Approaches ...............................10
      A.1. ...Through HTML/CSS Extensions ............................10
      A.2. ...Through Custom URI Schemes .............................10
   Appendix B.  Implementations ......................................10
      B.1. Example Implementation for Webfolder Client ...............10
      B.2. Xythos ....................................................14

1. Introduction πŸŽ€

Okay so, a WebDAV server ([RFC2518]) is an HTTP server too ([RFC2616]). That's just the definition, no cap πŸ’… Most WebDAV servers can be operated, at least partly, from an HTML-based UI in a browser. But it's often super desirable to switch from that HTML view to a native WebDAV client, which directly supports the authoring features defined in WebDAV and related specs ✨

This document specifies a platform-neutral mechanism based on dispatching documents by their MIME type. For completeness, Appendix A lists other approaches that existing clients have implemented πŸ¦‹

Here's an example: lots of educational institutions use WebDAV servers to share docs among students. Each student gets their own collection structure on the server, often called their "locker" πŸ” Ideally, when a student clicks a link on a university-provided HTML page (maybe their university web portal), an editable view of their locker just pops up πŸ™Œ

2. Terminology πŸ“š

The terminology here follows the WebDAV Distributed Authoring Protocol specification [RFC2518] 🫢

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] πŸ”₯

This document uses XML DTD fragments ([XML]) as a purely notational convention. Specifically:

  • Element names use the namespace "http://purl.org/NET/webdav/mount". When an XML element type in this namespace is referenced in this document outside of the context of an XML fragment, the string "dm:" will be prefixed to the element name.
  • Element ordering is irrelevant.
  • Extension elements/attributes (elements/attributes not already defined as valid child elements) may be added anywhere, except when explicitly stated otherwise.

3. Format 🧚

A WebDAV mount request is encoded in a specific XML format ([XML]) with a well-defined MIME type (see Section 6.1). That MIME type lets user agents dispatch the content to a handler specific to the system's WebDAV client πŸ’–

The elements below use the namespace "http://purl.org/NET/webdav/mount" πŸ’œ

<!ELEMENT mount (url, open?, username?) >

<!ELEMENT url (#PCDATA) >
<!-- PCDATA value: scheme ":" hier-part, as defined in Section 3 of
     [RFC3986] -->

<!ELEMENT open (#PCDATA) >
<!-- PCDATA value: path, as defined in Section 3 of
     [RFC3986] -->

<!ELEMENT username (#PCDATA) >

3.1. dm:mount 🌸

The <dm:mount> element is a container for all the other elements this protocol defines πŸŽ€

3.2. dm:url πŸ“

The mandatory <dm:url> element gives the HTTP URL of the WebDAV collection the client should mount πŸ¦‹

3.3. dm:open 🫧

The optional <dm:open> element tells the client to display a specified child collection. Its URL is computed by concatenating this element's value with the URL from the <dm:url> element (Section 3.2). (Section 7 explains why this element only displays collections instead of opening arbitrary documents, so go check it out πŸ‘€)

3.4. dm:username πŸ™ˆ

The server can use the optional <dm:username> element to name the currently authenticated principal. A client can use this value to pick a matching mount point, since different users may have mounted the same URL with different credentials under different local mount points. It can also give a meaningful default for authenticating against the server. A browser and a WebDAV client often don't share HTTP connections, so including this info in the mount document makes things more usable ✨

Implementation Note: If a <dm:username> element is present, public caching of the document should be disallowed. Thus, appropriate Vary or Cache-Control headers are needed in the server response πŸ”

4. Example 🎬

Let's walk through it πŸ’… In the example, the client first grabs a representation of a WebDAV collection using a generic web browser (1). The returned HTML has a hyperlink pointing to the "davmount" document in the format defined in Section 3 (2). The user follows that link (3), which makes the server return the "davmount" document to the user's browser (4). The browser then hands the content to whatever app is registered for the "application/davmount+xml" MIME type, which is usually the default WebDAV client on the user's system 🌈

(1) Client retrieves representation of WebDAV collection "/user42/inbox/".

GET /user42/inbox/ HTTP/1.1
Host: www.example.com

(2) Server returns representation.

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: xxx

..
<a href="?action=davmount">View this collection in your
WebDAV client</a>
..

(Note that the example only shows the part of the HTML page that contains the relevant link.)

(3) Client follows link to "davmount" document.

GET /user42/inbox/?action=davmount HTTP/1.1
Host: www.example.com

(4) Server returns "davmount" document.

HTTP/1.1 200 OK
Content-Type: application/davmount+xml
Content-Length: xxx
Cache-Control: private

<dm:mount xmlns:dm="http://purl.org/NET/webdav/mount">
  <dm:url>http://www.example.com/user42/</dm:url>
  <dm:open>inbox/</dm:open>
</dm:mount>

β‹― part 2 is coming with Section 5 and everything after it, bestie πŸ«ΆπŸ’–

9.1. Normative References

okay so these are the docs this spec leans on to work at all, bestie πŸ“šβœ¨

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2518] Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, February 1999.
  • [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
  • [RFC3023] Murata, M., St.Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
  • [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
  • [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", W3C REC-xml-20060816, August 2006, http://www.w3.org/TR/2006/REC-xml-20060816.

9.2. Informative References

these ones are more like bonus reading, not required homework πŸ§ πŸ’•

  • [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", RFC 3470, BCP 70, January 2003.
  • [WEBARCH] Walsh, N. and I. Jacobs, "Architecture of the World Wide Web, Volume One", W3C REC-webarch-20041215, December 2004, http://www.w3.org/TR/2004/REC-webarch-20041215/.

Appendix A. Alternative Approaches ✨

okay this appendix is the "what if we did it differently?" tour, and honestly some of these were giving chaos πŸŒ€

A.1. ...Through HTML/CSS Extensions

Microsoft Internet Explorer had a CSS extension that let you switch over to its own WebDAV client ("Webfolder", see http://msdn.microsoft.com/workshop/author/behaviors/reference/behaviors/anchor.asp) πŸͺŸ. BUT, at the time this was written, no other user agent had picked it up, so it was a lonely little feature πŸ₯².

A.2. ...Through Custom URI Schemes

the "kio" library of the "K Desktop Enviroment" (http://www.kde.org/) uses the URI scheme "webdav" to hand things off to the system's WebDAV client πŸ‰. That scheme isn't registered, and it isn't supported on other platforms either, so it's a no-go for the wider web πŸ™…β€β™€οΈ. The W3C's "Architecture of the World Wide Web, Volume One" also straight up says not to make up new schemes when an existing one can do the job πŸ“œ:

A specification SHOULD reuse an existing URI scheme (rather than create a new one) when it provides the desired properties of identifiers and their relation to resources.

(See [WEBARCH], Section 2.4.) πŸ’…

Appendix B. Implementations πŸŽ€

B.1. Example Implementation for Webfolder Client

this is a sample dispatcher for the application/davmount+xml datatype 🧁. It's built for Win32 systems and the Microsoft "Webfolder" client, so if you're on Windows, you can actually run this and see the magic happen ✨.

// sample implementation of application/davmount+xml
// dispatcher for Windows Webfolder client
//
// to install/uninstall:
//        wscript davmount.js
//
// to open the webfolder:
//        wscript davmount.js filename
// (where filename refers to an XML document with MIME type
// application/davmount+xml)

var EXTENSION = ".davmount";
var MIMETYPE = "application/davmount+xml";
var REGKW = "WebDAV.mount";
var NS = "xmlns:m='http://purl.org/NET/webdav/mount";

// remove keys/entries from the registry

function regdel(shell, key) {
  try {
    var x = shell.RegRead(key);
    try {
      shell.RegDelete(key);
    }
    catch(e) {
      WScript.Echo("Error removing key " + key + ": " + e);
    }
  }
  catch(e) {
    // entry not present
  }
}


// methods for registering/unregistering the handler

function install() {

  var WshShell = new ActiveXObject("WScript.Shell");
  if (WshShell == null) {
    WScript.Echo("Couldn't instantiate WScript.Shell object");
    return 2;
  }

  var fso = new ActiveXObject("Scripting.FileSystemObject");

  var RegExt = "HKCR\\" + EXTENSION + "\\";
  var RegMimeType = "HKCR\\MIME\\DataBase\\Content Type\\"
    + MIMETYPE + "\\";
  var RegKw = "HKCR\\" + REGKW + "\\";

  var extension = null;
  try {
    extension = WshShell.RegRead(RegMimeType + "Extension");
  }
  catch (e) {
  }

  if (extension == null) {
    var but = WshShell.popup("Install the dispatcher for mime type "
      + MIMETYPE + "?", 0, MIMETYPE + " installation", 4);

    if (but == 6) {
      try {
        WshShell.RegWrite(RegExt, REGKW);
        WshShell.RegWrite(RegExt + "Content Type", MIMETYPE);
        WshShell.RegWrite(RegMimeType + "Extension", EXTENSION);
        WshShell.RegWrite(RegKw, "WebDAV Mount Request");
        WshShell.RegWrite(RegKw + "DefaultIcon\\",
          "shell32.dll,103");
        var path = fso.getAbsolutePathName("davmount.js");
        WshShell.RegWrite(RegKw + "shell\\open\\command\\",
          "%SystemRoot%\\system32\\wscript.exe /nologo \""
          + path + "\" \"%1\"", "REG_EXPAND_SZ");
      }
      catch (e) {
        WScript.Echo("Error writing to registry");
        return 1;
      }

      return 0;
    }
    else {
      return 1;
    }
  }
  else {
    var but = WshShell.popup("Remove the dispatcher for mime type "
      + MIMETYPE + "?", 0, MIMETYPE + " installation", 4);

    if (but == 6) {
      regdel(WshShell, RegExt + "Content Type");
      regdel(WshShell, RegExt);
      regdel(WshShell, RegKw + "shell\\open\\command\\");
      regdel(WshShell, RegKw + "DefaultIcon\\");
      regdel(WshShell, RegKw);
      regdel(WshShell, RegMimeType + "Extension");
      regdel(WshShell, RegMimeType);
      return 0;
    }
    else {
      return 1;
    }
  }
}


if (WScript.Arguments.length == 0) {
  // install/uninstall
  WScript.Quit(install());

}
else {
  // try to invoke Webfolder

  var inp = new ActiveXObject("MSXML2.DOMDocument");
  var furi = encodeURI(WScript.Arguments(0));
  if (! inp.load(furi)) {
    WScript.Echo("Can't read from '"
      + WScript.Arguments(0) + "'!");
    WScript.Quit(2);
  }

  inp.setProperty("SelectionLanguage", "XPath");
  inp.setProperty("SelectionNamespaces",
    "xmlns:m='http://purl.org/NET/webdav/mount'");

  var n1 = inp.selectSingleNode("/m:mount/m:url");
  var n2 = inp.selectSingleNode("/m:mount/m:open");

  if (n1 == null) {
    WScript.Echo("<url> element missing.");
    WScript.Quit(2);
  }

  var ie = new ActiveXObject("InternetExplorer.Application");

  ie.Navigate("about:blank");
  var doc = ie.Document;

  var folder = doc.createElement("span");
  folder.addBehavior("#default#httpFolder");

  var result = folder.navigate(n1.text +
                 (n2 == null ? "" : n2.text));

  // close the window again when there was no <open> element
  if (n2 == null) ie.Quit();

  if (result != "OK") {
    if (result == "PROTOCOL_NOT_SUPPORTED") {
      WScript.Echo("This site doesn't seem to support WebDAV.");
      WScript.Quit(1);
    }
    else {
      WScript.Echo("Unexpected status: " + result);
      WScript.Quit(2);
    }
  }

}

B.2. Xythos

the "Xythos Drive" WebDAV client supports this specification starting with version 4.4 πŸŒŸπŸ’œ

Author's Address πŸ—ΊοΈ

Julian F. Reschke
greenbytes GmbH
Hafenweg 16
Muenster, NW  48155
Germany

Phone: +49 251 2807760
Fax:   +49 251 2807761
EMail: julian.reschke@greenbytes.de
URI:   http://greenbytes.de/tech/webdav/

Copyright (C) The Internet Society (2006).

this document is subject to the rights, licenses and restrictions in BCP 78, and except as set out there, the authors keep all their rights πŸ”’.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. πŸ™ƒ

Intellectual Property 🧾

the IETF doesn't take a position on whether any Intellectual Property Rights or other rights claimed to cover this technology are valid or in scope, or on whether a license under them would be available πŸ€·β€β™€οΈ. It also doesn't say it went looking for those rights itself. Info on how rights work for RFC documents is in BCP 78 and BCP 79 πŸ“š.

Copies of IPR disclosures made to the IETF Secretariat, plus any assurances of licenses to be made available, or the results of an attempt to get a general license or permission to use those proprietary rights for implementers or users of this spec, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr πŸ—‚οΈ.

the IETF invites anyone interested to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org πŸ“¬.

Acknowledgement πŸ™

Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) πŸ’–

πŸ“¦ where this page comes from