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

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 26 Mar 2001 17:46:23 -0800

Accidentally caught by the spam filter.  I've added <[email-masked]> to
the accept2 list, so future emails will go through to the list.

- Jim

-----Original Message-----
From: Philippe Verdy [mailto:[email-masked]]
Sent: Monday, March 26, 2001 1:26 PM
To: [email-masked]
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...

---

From: "Jim Whitehead" <[email-masked]>
Date: Mon, 26 Mar 2001 18:23:43 -0800

> There's a big problem with WebDAV : it requires HTTP server
> extensions such as:

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

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

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

> implementation he needs to work with its own DAV-aware client.

This capability is covered by the OPTIONS method in HTTP.

> 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

---

From: "Philippe Verdy" <[email-masked]>
Date: Tue, 27 Mar 2001 11:47:20 +0200

Your answer is informative, but it still does not solve the problem of seb
servers that only implement the basic methods: GET, HEAD, OPTIONS, and
TRACE.
A simple test on many web servers (despite they are using a recent Apache
version with mod_perl extension, and even with mod_php allowed), will reveal
that most of web servers used by web hosting providers do not allow any DAV
protocol because of these limitation:

To test it, just use the following telnet session to the HTTP port of the
webserver:

>> Request:
telnet www.webhostingprovider.net 80
OPTIONS / HTTP/1.1
Host: www.webhostingprovider.net

>> Answer:
HTTP/1.1 200 OK
Date: Tue, 27 Mar 2001 08:11:50 GMT
Server: Apache/1.3.12 (Unix) Debian/GNU mod_modperl/1.24
Content-Length: 0
Allow: GET, HEAD, OPTIONS, TRACE

This (sample) session clearly indicates that DAV cannot work on that
webserver, because the required methods are not implemented and I really
think that most web hosting providers won't change the current rules of
publishing via FTP only...

Note that to test the presence of a POST method, you have to find a resource
that accepts such posts. Classic default resources for paths only have a
default .html file that does not support POST. But, if the default ressource
pointed by the home directory is a file like index.php3 which could perform
useful actions on POSTS or on other methods, you will see the following
result for the same request:

>> Answer:
HTTP/1.1 200 OK
Date: Tue, 27 Mar 2001 08:11:50 GMT
Server: Apache/1.3.12 (Unix) Debian/GNU mod_modperl/1.24
Content-Length: 0
Allow: GET, HEAD, POST, OPTIONS, TRACE

And thus, there is still no support for other methods, and users are sticked
not to use DAV at all, despite they could use an encapsulation of it using
POST requests (publishing a web page could also be performed using standard
HTML forms which would send the result with the POST method).

I think personally that a light version of DAV without HTTP server extension
is possible now, without modifying the server to enable new HTTP extensions,
and without changing the core of DAV. If the conceptors of DAV do not want
to implement it, users will do it themselves !

Your answer suggests me that I could form a group to implement an
encapsulation of DAV over POST, using a simple encapsulation of XML requests
within a new XML container that specifies the method documented by DAV, such
that the following session example to PUT a resource on the web server,
using a POST-encapsulation:

>> Request from client to the script run at web server:

POST /myaccount/scripts/postDAV.php
Host: www.provider.com
Content-Type: multipart/mixed; boundary="-----=NextPart:postDAV-----"
Content-Length: 0

-----=NextPart:postDAV-----
Content-Part: request
Content-Type: text/xml; encoding=UTF-8
Content-Transfer-Encoding: 8bit
Content-Length: xxx

<xml ns="postdav">
<webdav>
  <auth method="basic" realm="">
    <user>myownlogin</user><!-- encoded in Base64 -->
    <password>XYZdf5ggrv</user><!-- encoded in Base64 -->
  </auth>
  <request method="PUT" resource="/myresource-to-publish.html"
version="HTTP/1.1">
    <tag>123456-8F3C-83FE0012</tag><!-- random number from client -->
    <meta http-equiv="Host" content="www.provider.com" />
    <body id="body" /><!-- indicates the tag of the content-part -->
  </request>
</webdav>
</xml>

-----=NextPart:postDAV-----
Content-Part: body
Content-Type: text/html; encoding=iso8859-1
Content-Transfer-Encoding: 8bit
Content-Length: xxx

<!DOCTYPE HTML ...>
<html>
<head>
   ...
</head>
<body>
   ...
</body>
</html>
-----=NextPart:postDAV-----

>> Answer from the script run at web server:

HTTP/1.1 200 OK <!-- should always be OK -->
Date: Tue, 27 Mar 2001 08:11:50 GMT
Server: Apache/1.3.12 (Unix) Debian/GNU mod_modperl/1.24
Content-Length: 0
ETag: "9DB189-FC02-38A40031"
Content-Type: multipart/mixed ; boundary="-----=NextPart:postDAV-----"
Content-Length: 0

-----=NextPart:postDAV-----
Content-Part: answer
Content-Type: text/xml; encoding=UTF-8
Content-Transfer-Encoding: 8bit
Content-Length: xxx

<xml ns="postdav">
<webdav>
  <answer version="HTTP/1.1" status="200" title="OK"><!-- effective DAV
status -->
    <tag>123456-8F3C-83FE0012</tag><!-- random number from client -->
    <body part="body"/><!-- optional: only if DAV specifies a body for the
answer -->
  </answer>
</webdav>
</xml>
-----=NextPart:postDAV-----
Content-Part: body
Content-Type: text/html; encoding=iso8859-1
Content-Transfer-Encoding: 8bit
Content-Length: xxx

<!DOCTYPE HTML ...>
<HTML>
<HEAD>
  <TITLE>WebDAV Answer - HTTP/1.1 200 OK</TITLE>
</HEAD>
<BODY>
  <H1>WebDAV Answer</H1>
  <H2>Your request:</H2>
  <BLOCKQUOTE>
    <P>PUT /myresource-to-publish.html HTTP/1.1</P>
    <P>Tag: 123456-8F3C-83FE0012</P>
  </BLOCKQUOTE>
  <H2>Has returned with the following status:</H2>
  <BLOCKQUOTE>
    <P><B>HTTP/1.1 200 OK</B></P>
    <P> </P>
    <P>The resource has been accepted and is now online.</P>
  </BLOCKQUOTE>
</BODY>
</HTML>
-----=NextPart:postDAV-----

---

From: "Philippe Verdy" <[email-masked]>
Date: Tue, 27 Mar 2001 12:17:07 +0200

Sorry for the 2 typos in the sample in the sample session at end of my
previous message:
- The 1st line with POST in the request lacks a " HTTP/1.1" protocol version
specifier at end
- The <password> element in the XML of the request should terminate with
</password> and not </user>

An important remark: The sample session would work through existing HTTP
proxies which, despite Jim said, will persist in their current
implementation for much more than 2 years and cause much problems to network
administrators who cannot change their implementation easily (there are
hardware proxies that are sold still now, that still only implement the
basic HTTP 1.0 or 1.1 protocol, with no support for HTTP extensions)...

The problem is more general than WebDAV: this will affect all attempts to
support HTTP extensions using the RFC published by the W3C. But I think that
an encapsulation like the one I propose, can provide a gateway for such
extensions that are not supported for now by existing hardware and software
solutions: the problem can be solved not within the network, but at both
ends.

My solution can be viewed as a tunnel to support any future HTTP extension,
and I think it has many important applications: a client could first try to
use the HTTP extension directly, but if that fails, it could retry using an
HTTP encapsulation as well...
So the XML model that I propose could be more generic so that the XML
namespace it uses can accept all future HTTP extensions.

---

From: Greg Stein <[email-masked]>
Date: Tue, 27 Mar 2001 03:11:33 -0800

> protocol because of these limitation:

Okay, so you're suggesting that, say, Apache users cannot use DAV because
they don't have mod_dav installed. Fair enough, and entirely true.

Then, you go on to state that your PHP-based solution will solve the
problem. Not at all. I would still need to install that on my system.

All you've done is changed "install mod_dav" to "install PHP and this
script". That doesn't help anything.

> and without changing the core of DAV.

You *still* have to modify the server to enable your tunneled protocol.

> If the conceptors of DAV do not want

Fine. Please feel free.

Implement it to your heart's content. I don't see Microsoft changing their
clients (Web Folders, Office, etc). I don't see Joe Orton upgrading his
clients. I doubt gnome-vfs will switch. I can't see Adobe changing all of
their clients to use it. etc etc.

DAV has widespread buy-in in its current form.

Which users do you believe *want* this kind of change? And which users will
be writing the code to make the change?

> encapsulation of DAV over POST,

You sure can. Nobody can prevent you from doing such a thing. I just don't
see that you'll get any buy-in to the approach.

The only benefit to the tunneling approach is proxy/firewall navigation. In
my experience, that has impacted relatively few people. I also believe Jim
is incorrect with his "2 years" timeline. Proxies started updating their
code about two years ago. Many proxies are now DAV-capable and are being
deployed. Again, it is rare that I see a problem report due to a proxy
problem.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/

---

From: Bruce Williams <[email-masked]>
Date: Tue, 27 Mar 2001 03:49:06 -0800

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" <[email-masked]>
To: "WebDAV WG" <[email-masked]>
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 ?

---

From: "Larry Masinter" <[email-masked]>
Date: Tue, 27 Mar 2001 23:09:04 -0800

The decision to use separate methods instead of just POST (which
I think was the original question) was arrived at after a lengthy
discussion; the first record I can find is from October 1996:

 http://lists.w3.org/Archives/Public/w3c-dist-auth/1996OctDec/subject.html#25

Note that SOAP takes a different view; it only uses POST. I don't
think the considerations have changed substantially, except perhaps
that we're talking about using other headers and/or message body
elements rather than content-type to do method dispatching.

Larry
-- 
http://larry.masinter.net