W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2001

FW: Why not an encapsulation for DAV over standard HTTP 1.0 or 1.1 without required server extension ?

From: Jim Whitehead <ejw@cse.ucsc.edu>
Date: Mon, 26 Mar 2001 17:46:23 -0800
To: "WebDAV WG" <w3c-dist-auth@w3.org>
Accidentally caught by the spam filter.  I've added <verdy_p@wanadoo.fr> to
the accept2 list, so future emails will go through to the list.

- Jim

-----Original Message-----
From: Philippe Verdy [mailto:verdy_p@wanadoo.fr]
Sent: Monday, March 26, 2001 1:26 PM
To: w3c-dist-auth@w3.org
Subject: [Moderator Action] Why not an encapsulation for DAV over
standard HTTP 1.0 or 1.1 without required server extension ?

There's a big problem with WebDAV : it requires HTTP server extensions such
- too many new responses

It causes many problems to users:
- It is unlikely that many web servers will be upgraded to support them.
- The protocol does not fit well on many HTTP proxies
- Many web hosting companies that use a shared server won't accept to add
such extensions (the same ones refuse to implement the so-called FrontPage
extension for security reasons)
- Users are restricted to publish their web site via FTP only

- PHP works on classic HTTP 1.0 and 1.1 servers without HTTP extension for
- PHP is considered very secure (enough to let web hosting companies accept
PHP scripts from their users), and accepted as a valid server extension (and
it is already ported to many environments and for many web server
- PHP has a strong support from both users and web hosting companies and has
enough capabilities to support a protocol like DAV. This makes DAV
implementation possible through a single DAV-compliant script written in
- The PHP DAV script can be updated by users themselves and can easily
follow the new standards for DAV, without requiring any change on the web
server (the web server will just need to support at least a basic version of
PHP3). Users can simply upload the new PHP DAV script using a single FTP
transfer to their own account (the PHP script would also contain the name of
a user-provided parameter file, which could be also uploaded with FTP, and
the name of the DAV script resource if it has to be write-protected from DAV
- Other scripting extensions may also be used alternatively to PHP in the
future, if such scripting languages are accepted.

So why not extending the draft specification of DAV, to allow an
encapsulation of the current DAV specification in a single XML request that
would contain the DAV method requested and the required credentials ?

People would then post to http://webserver/~user/dav/post.php, using POST
methods, in multipart/mixed format when posting resource contents, and the
answers to the DAV request would not depend on HTTP server responses (the
DAV response sould be in the XML response resulting from the HTTP POST
request). this would be done instead of specifying the default
http://webserver/ address for the main DAV implementation.

Additionally, the multipart/mixed format could be used to accelerate the
transfer of multiple resources, by using a single chunked multipart/mixed

I also suggest that the protocol includes the HELP method, to get the list
of accepted DAV methods (like it currently exists in FTP), so that a client
can query the capabilities of the DAV server (does it support lock/unlock
methods ? and so on...) and so that the client can adapt to future versions
of the DAV protocol. Note that the same server could then host several
versions of the DAV protocol, because each user could choose and upload the
implementation he needs to work with its own DAV-aware client.

I personnally think it's a very bad idea to link the DAV protocol to the
HTTP protocol itself. And there's a way make both coexist separately...
Received on Monday, 26 March 2001 20:47:43 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:22 UTC