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

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
as:
- new methods: MKCOL, PUT, FINDPROP, DELETE, COPY, MOVE, DELETE, LOCK,
UNLOCK
- 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

But:
- PHP works on classic HTTP 1.0 and 1.1 servers without HTTP extension for
DAV
- 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
implementations)
- 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
PHP.
- 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
itself).
- 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
request.

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