W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2002

WebDAV and Open Pluggable Edge Services

From: Lisa Dusseault <ldusseault@xythos.com>
Date: Wed, 20 Mar 2002 13:12:11 -0800
To: <w3c-dist-auth@w3.org>
Message-ID: <002c01c1d053$e7cded20$ecba3fa6@moose>

I've been watching the OPES (Open Pluggable Edge Services) WG work and thus
I've developed some concerns about how edge services interoperate with
authoring clients.

Edge services in the Web are services which may review or modify content at
the "edge" of the Web, that is, between the origin content server and the
end-consumer browser.  For example, an edge service might be a company's
HTTP proxy, which could perform virus scanning and reject virus payloads.
Another simple example is a translation service -- in this case, the edge
service might be addressed explicitly by the client in order to have the
content transformed.

Transparent edge services do not interoperate easily with authoring
applications that rely on HTTP GET to retrieve source.  This obviously
applies to WebDAV.  It is time for us to solve the problem of retrieving
source, so that we can give our input to OPES as it develops.

Some initial thoughts about this:

1.  It seems unreasonable for existing WebDAV clients to wait for various
OPES standards to be defined and then implement those protocols in order to
request edge services *not* to be performed.  Either edge services should
not transform data without explicitly being asked (and that is being
considered in the WG) or authoring clients should add information to
requests now to signal that edge services aren't desired.  Note that neither
is secure because nothing stops rogue edge services from performing
transformation anyway.

2.  The situation could be made easier if all WebDAV clients were able to
include a header in GET requests indicating that the request is being made
by an authoring client, not a browsing client.  I suggest a header rather
than a method, because a new method will not be supported for much longer,
and won't interoperate with non-WebDAV servers.

3.  The source property is no help in this situation.  Doing a PROPFIND can
get you the source property, but then a GET to the URL in that property may
be subject to the same edge service transformations as the original URL.

4.  End-to-end encryption and/or signatures are the ultimate way to stop
edge services from transforming data.  Perhaps the spec coudl use a
recommendation that WebDAV servers SHOULD support TLS, and that WebDAV
clients SHOULD attempt to use TLS, even for content that is also available
unencrypted.  However, there are some unsolved issues here.  How does the
client discover that the content available over TLS is the same as the
content available over unsecured HTTP, in cases where the content doesn't
need to be secured by TLS for ordinary browsers?  Note that it's equally
possible for the server to host *different* content on ports 80 and 443, so
the client must be able to differentiate the two cases.

I do not have strong preferences but I have many concerns.  I'd like to see
solid proposals with discussions of all the known issues, and lots of
feedback on what proposals would be *acceptable*.  This may be a situation
where a large part of the community may have to accept a proposal that is
not their preferred proposal if it is at least acceptable.

Received on Wednesday, 20 March 2002 16:39:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:25 UTC