© 1999 Sami Itkonen
<si@iki.fi>Last Updated: Apr 19 1999
2 Evolution of HTTP and Remote Authoring
GET. A client
would send the line
GET document.html CRLFto the server to fetch the required document. There was no method for the client to submit information to the server.
Although no formal RFC existed for HTTP until 1996, the protocol evolved based on what the servers and clients did. HTTP/1.0 included many enhancements over the older version of protocol; the server could now send additional meta-information to the client in preceding headers and the client was allowed to perform multi-line requests. Like other text-based internet protocols (SMTP, FTP, NNTP etc), the HTTP server could also respond to a client's request with a status code.
Along with GET, a new method was devised that would allow
the transfer of arbitrary data from the client to the server:
POST. With the support for forms in Web browsers,
real interactivity was now possible for the users.
PUT and DELETE are
the most relevant in concern to remote authoring. These methods, like
their counterparts in the FTP protocol, store and remove
resources on the server.
The difference between POST and PUT is that
the URI in POST method request identifies the resource
that will handle the data (typically a CGI script or equivalent), while
the functionality of PUT is opposite to that of
GET: it identifies the resource where the data must be stored to.
For example, the request
PUT /files/document.html HTTP/1.1will store the enclosed data that is supplied after the method under the URI /files/document.html. This difference in crucial to the operation of remote Web publishing tools. [1,7]
< .. headers .. > CRLF
< .. message .. > CRLF
PUT and DELETE -
were necessary to accomplish this, they were by no means
sufficient.
Remote authoring tools that can exploit the HTTP protocol to publish
documents have existed for several years. Since there was no standard
for remote publishing, each tool either had to extend the HTTP protocol
in its incompatible way or give up on distributed authoring
[12,15].
The stated goal of the WebDAV working group was (from the charter) to "define the HTTP extensions necessary to enable distributed web authoring tools to be broadly interoperable, while supporting user needs", and in this respect DAV is completing the original vision of the Web as a writeable, collaborative medium [13].
Since no read lock has traditionally been required to read a Web page, a write lock is the only type of lock specified. The specification does not rule out the creation of locks of other types later, though. To maintain backwards compatibility with traditional HTTP clients, a WebDAV-compliant server is not required to support locking. [5,15]
The duration of a lock is independent of any individual network connection [13]. It is also possible to lock multiple resources at the same time and to lock a resource without actually retrieving it [12].
SEARCH, to perform the search.
The value of properties is increased as DASL provides
an efficient an convenient method for searching resources based on
their properties.
| Method | Description |
|---|---|
| LOCK | This method locks a resource. Using this method does guarantee that no-one except the holder of the lock will be able to modify the resource, as the specification does not require a WebDAV compliant server to use mandatory locks. If used on collections, a Depth header may be used to recursively lock all the members in the collection. |
| UNLOCK |
Unlock a resource. Any WebDAV compliant server which implements the
LOCK is required to support UNLOCK too. All
general
notes for LOCK apply to UNLOCK as well.
|
| PROPFIND | Retrieve the properties of the resource as identifed in the request. A recursive listing is also possible if the resource is a collection itself. |
| PROPPATCH | Modifies the properties of the resource as identifed in the request. As the name suggests, this method does not replace all the properties, but it "patches" the properties by setting/removing individual property elements. |
| COPY |
This method duplicates the source resource identified in the request to
the destination as specified by the Destination header. No
guarantee is made that the resource or properties can be copied
identically; the server will make a "best effort".
If |
| MOVE |
This method consist of atomically processed operation
a logical equivalent of COPY
followed by a consistensy check and the removal of the source.
All general
notes for COPY apply to MOVE as well.
|
| MKCOL |
MKCOL creates a collection. No recursive operation is
supported by this method, that is, the parent collection of the new
collection to be created must already exist.
|
| Refinements for methods defined by HTTP/1.1 | |
| PUT |
As defined in HTTP/1.1 the PUT method will replace the
resource if it already exists. The method is not defined for the
creation of collections; MKCOL is recommended to be
used instead.
|
| GET and HEAD |
The semantics of GET are unchanged when applied to a collection,
since GET is defined as, "retrieve whatever information
(in the form of an entity) is identified by the Request-URI"
[3,5]. For this reason, the actual operation that
happens in this case is undefined.
Likewise HEAD in not affected
since it is defined as GET without a message body.
|
| POST |
As the operation performed by POST depends on the server,
no meaningful behavior can be defined for this method either when applied
to collections.
|
| DELETE |
If DELETE is applied for collections, a Depth header
with value "infinite " is assumed to be present and so the
delete operation will be recursive.
|
PUT
method described in HTTP/1.1. These include Microsoft Frontpage, AOLPress
and Netscape Communicator. Few products are WebDAV-compliant yet,
clients that support WebDAV now or in the future include Microsoft
Internet Explorer 5, NetObjects Fusion and Microsoft Office 2000. A number
of Open Source solutions also exist.
[2,15,16]
Apache, the most popular Web server, does not fully support HTTP/1.1 and
contains no support for WebDAV. Two modules exist that can add
distributed authoring support to Apache: mod_put and mod_dav.
The former only implements PUT and DELETE,
so that HTTP/1.1-aware Web clients can be used for authoring, while the
latter is aimed to provide full WebDAV compliance for Apache.
[1,14]
Another advantage is that WebDAV uses XML, which means that the protocol itself can be extended without fragmenting it (like it happened to HTML). Part of their success of the Web is because the underlying protocols, HTML and HTTP, are simple and yet powerful - and they are based on text, which made them easier to adopt.
Whether WebDAV will have an obsoleting impact on the currently dominating technologies like FTP and CVS (like it had on gopher, for example) or if it's just another case of reinventing the wheel remains to be seen. The usual dogma applied for situations like this is "don't fix it if it isn't broken" - WebDAV shouldn't be used if the old technology already works well. However, as there is lot to gain from WebDAV, it will certainly be the main focus of new developments related any kind of distributed computing.
| [1] | Anon, Apache Week, Publishing Pages with PUT, April 4 1997 [referred April 18, 1999] |
| < http://www.apacheweek.com/features/put > | |
| [2] | Best, Michael, WebDAV Projects, April 12, 1999 [referred April 18, 1999] |
| < http://www.webdav.org/projects/ > | |
| [3] | Fielding, et al, RFC 2068: Hypertext Transfer Protocol -- HTTP/1.1, January 1997 [referred April 18, 1999] |
| < ftp://ftp.funet.fi/pub/standards/RFC/rfc2068.txt > | |
| [4] | Franks, et al, RFC 2069: An Extension to HTTP : Digest Access Authentication, January 1997 [referred April 18, 1999] |
| < ftp://ftp.funet.fi/pub/standards/RFC/rfc2069.txt > | |
| [5] | Goland, et al, RFC 2518: HTTP Extensions for Distributed Authoring -- WEBDAV, February 1999 [referred April 18, 1999] |
| < ftp://ftp.funet.fi/pub/standards/RFC/rfc2518.txt > | |
| [6] | Goland, HTTP Design Issues, lessons from WebDAV's Property and Depth head er experiences, December 24, 1998 [referred April 18, 1999] |
| < http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0303.html > | |
| [7] | Hethmon, Paul S, Illustrated Guide to HTTP: Chapter 2, 1997 [referred April 18, 1999] |
| < http://www.manning.com/Hethmon/Chapter2.html > | |
| [8] | Kaler, et al, IETF Draft: Versioning Extensions to WebDAV, January 20, 1999 [referred April 18, 1999] |
| < http://www.ics.uci.edu/pub/ietf/webdav/versioning/draft-ietf-webdav-versioning-01.txt > | |
| [9] | Leach, Goland, IETF Draft: WebDAV ACL Protocol, November 10, 1997 [referred April 18, 1999] |
| < http://www.ics.uci.edu/pub/ietf/webdav/acl/draft-ietf-webdav-acl-00.txt > | |
| [10] | Reddy, et al, IETF Draft: DAV Searching & Locating, November 18, 1998 [referred April 18, 1999] |
| < http://www.ietf.org/internet-drafts/draft-reddy-dasl-protocol-04.txt > | |
| [11] | Slein et al, IETF Draft: WebDAV Advanced Collections Protocol, February 26, 1999 [referred April 18, 1999] |
| < http://www.ics.uci.edu/pub/ietf/webdav/collection/draft-ietf-webdav-collection-protocol-03.txt > | |
| [12] | Slein, et al, RFC 2291:Requirements for a Distributed Authoring and Versioning Protocol for the World Wide Web, February 1998 [referred April 18, 1999] |
| < ftp://ftp.funet.fi/pub/standards/RFC/rfc2291.txt > | |
| [13] | Stein, Greg, DAV Frequently Asked Questions, February 23, 1999 [referred April 18, 1999] |
| < http://www.webdav.org/other/faq.html > | |
| [14] | Stein, Greg, mod_dav: a DAV module for Apache, April 7, 1999 [referred April 18, 1999] |
| < http://www.webdav.org/mod_dav/ > | |
| [15] | Whitehead, Jim and Higgins, Meredith, WEBDAV: IETF Standard for Collaborative Authoring on the Web, September/October, 1998 issue of IEEE Internet Computing, pages 34-40 [referred April 18, 1999] |
| < http://www.ics.uci.edu/pub/ietf/webdav/intro/webdav_intro.pdf > | |
| [16] | Whitehead, Jim, IETF WEBDAV Working Group, April 7, 1999 [referred April 18, 1999] |
| < http://www.ics.uci.edu/pub/ietf/webdav/ > |