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

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.

Received on Tuesday, 27 March 2001 05:20:51 UTC