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

As someone who is not-so-involved (hee hee - an asset?) in WebDAV that I
have a lot invested in the curent structure, may I comment?

WebDAV is going to be used where and by the "people who use it". ( duh )

If a website or app has WebDAV as a part of it's function, then they write
the code or install the mod_dav or whatever.

I am making light of this in a kidding way, because the problem stated is
just not that serious. The use of WebDAV in a practical manner by an
organization has more serious implications than installing a mod ( like
influencing vendor/app choices, training, etc ).

Bruce Williams
---------------------------------------------------
I love deadlines.
I like the whooshing sound they make as they fly by.
Douglas Adams


----- Original Message -----
From: "Jim Whitehead" <ejw@cse.ucsc.edu>
To: "WebDAV WG" <w3c-dist-auth@w3.org>
Sent: Monday, March 26, 2001 5:46 PM
Subject: 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 Tuesday, 27 March 2001 06:49:26 UTC