RE: 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

First, a clarification.  The HTTP/1.1 specification (RFC 2616, which you
haven't read) specifies the methods DELETE and PUT.  The WebDAV Distributed
Authoring specification (RFC 2518) specifies MKCOL, COPY, MOVE, LOCK,
UNLOCK, PROPFIND (FINDPROP isn't in RFC 2518) and PROPPATCH.

Second, the entire point of WebDAV was to define a set of HTTP extensions
for distributed authoring. To do this, we decided to take advantage of
HTTP's designed-in paths of extensibility, namely creating additional
methods and response codes. If you talk to Roy Fielding or Henrik Nielsen,
you'll find that HTTP was intentionally designed to be extended by adding
new methods and new status codes.  Doing this is not a problem.

> It causes many problems to users:
> - It is unlikely that many web servers will be upgraded to support them.

In fact, the market leading Web servers already support the protocol.
Microsoft's IIS 5 and the mod_dav module for Apache both support WebDAV.
IIS and Apache togther account for 75%+ of Web sites on the Internet
(according to Netcraft).

> - The protocol does not fit well on many HTTP proxies

HTTP proxies that do not implement the HTTP/1.1 protocol correctly may have
problems passing through WebDAV methods. In my view, this is a temporary
problem with the existing installed base of 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)

WebDAV can be significantly more secure than FTP for remote site update,
since WebDAV implementations typically do not give users a login account
(and many FTP servers do).

> - Users are restricted to publish their web site via FTP only

WebDAV can easily be used as an alternative to FTP.

> 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 ?

I'm not an expert on PHP, so take this with a grain of salt. Typically
security policies are based on the kind of operations supported by a
protocol.  If a server doesn't want to support remote writing and namespace
manipulation, it won't matter how the protocol is marshalled: as PHP, as XML
sent via POST, or some other way -- the server operator will disable the
facility if they do not want their users accessing the capability.  You
might be able to take advantage of a small 2-3 year window while proxy and
firewall vendors catch up to the new capability, but in the end the ability
to prevent the undesired operations will be added, and administrators will
shut down the avenue of access.

So, DAV over PHP seems like it would gain a minor 2-3 year advantage at
best. Accomplishing this would take a lot of work.  And at the end of it
all, existing DAV applications wouldn't be able to interoperate with a DAV
over PHP server.  To me it seems like much less work to try and address some
of the DAV shortcomings (certainly upgrading a proxy server is much easier
than figuring out how to re-marshall the protocol elements).

> 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.

This capability is covered by the OPTIONS method in HTTP.

> 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...

I disagree. As evidence of the benefits of the DAV-as-HTTP approach, I
present the list of existing HTTP clients and servers at
http://www.ics.uci.edu/pub/ietf/webdav/.

- Jim

Received on Monday, 26 March 2001 21:25:24 UTC