Subject: WebDAV and Open Pluggable Edge Services

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 20 Mar 2002 13:12:11 -0800

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.

Lisa

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 20 Mar 2002 15:02:23 -0800

Authoring clients do not go through edge services, period.  DAV clients
always operate on the origin of content, not replications of it.  If an
edge service (transformation configuration) itself is authorable, then
it will be authored via a completely different authority than the resources
that it transforms.

....Roy

---

From: "Lisa Dusseault" <[email-masked]>
Date: Wed, 20 Mar 2002 18:04:28 -0800

I don't think you understand.  If I'm sitting inside a large company, trying
to author a page from a site that's out on the internet, that page may
already be subject to transformations from transparent edge services.  For
example, the company firewall may be filtering viruses downloaded via HTTP.
More insidious, if I get my internet service from a struggling ISP, they
could replace banner ads on incoming messages with their own banner ads.

The OPES WG at the IETF is dealing with these issues directly.  The IAB has
suggested that edge services should not be transparent -- that clients must
explicitly ask for edge services.  However, even an IETF demand for there
not to be transparent edge services isn't a guarantee that there won't be
any.  You could say that the authoring issues are an argument against
encouraging transparent edge services, but those issues certainly don't make
transparent edge services not exist.

Lisa

> -----Original Message-----
> From: Roy T. Fielding [mailto:[email-masked]]
> Sent: Wednesday, March 20, 2002 3:02 PM
> To: Lisa Dusseault
> Cc: [email-masked]
> Subject: Re: WebDAV and Open Pluggable Edge Services
>
>

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 20 Mar 2002 20:39:46 -0800

> example, the company firewall may be filtering viruses downloaded via HTTP.

I don't think that DAV clients should be able to bypass that one, but they
can via a tunnel.

> could replace banner ads on incoming messages with their own banner ads.

I don't think people will allow banner ads to be edited through anything
less secure than a VPM or SSL tunnel, for obvious reasons.

> transparent edge services not exist.

I wouldn't argue that at all.  What you should consider, however, is that
if there is a plain HTTP mechanism for routing requests unmolested through
an interception device (which is not called an edge service), then what
makes you think that only DAV clients would want to use it?  And, once that
happens, why would the molesters honor the plain HTTP mechanism?

....Roy

---

From: "Larry Masinter" <[email-masked]>
Date: Thu, 21 Mar 2002 11:16:15 -0800

I'm reviewing the HTTP spec and the Cache-Control: no-transform
directive; RFC 2616 section 14.9.5. 

To prevent transformations of authored content, servers could
respond, when the client is "authoring", with a no-transform.

But I'm less sure of the utility of the Cache-Control: no-transform
request; does it mean "don't transform the request" or does
it mean "don't transform the response?". And would it apply
to an origin server as another way of saying a kind of "translate"?

Note that authoring clients should be sensitive to
Warning 214 (Transformation applied). At least, then
there would be some belief that they wouldn't inadvertently
try to let the user edit something that wasn't the original
source.

I'm not sure how a DAV server would know whether to supply
a cache-control: no-transform if clients distinguish between
the resource and its source by the "DAV:source" property.

(I was also wondering about the interaction between
cache-control: no-transform and the vary header. A response
with no-transform and one without no-transform are different.
So if the decision to supply no-transform depends on a request
header, then should the result Vary by that request header?)

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

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 22 Mar 2002 13:22:16 +0100

> respond, when the client is "authoring", with a no-transform.

That would set us back to sending Translate headers.

> to an origin server as another way of saying a kind of "translate"?

Hmm, 2616 is only speaking of content (and Content- headers). The
examples are with server responses.

I think modifying client requests is a no-no. Otherwise I
hope Internet Explorer sets "no-transform" when I'm online
shopping...

> try to let the user edit something that wasn't the original

Everyday you learn some new HTTP Headers...;)

> the resource and its source by the "DAV:source" property.

Can a "source" resources (listed in some other resource's
DAV:source property) have own DAV:source properties?
Must a resource designated as "source" be editable (e.g. support
PUT) and will that PUT influence the content of its
derived resource? When?

I think we need clarification of the "source" concept. When
do resources have a "source" relation?
- ASP/JSP pages
- shtml
- executables, object files and source code
- resources derived from a "master" with stylesheets
- ...

Which of these examples do we want to provide a solution
for with DAV:source?

> header, then should the result Vary by that request header?

I'm not really a fan of new HTTP methods, but just for interest:
Wouldn't a new method like "EDIT" which retrieves the editable
content of a resource make our life easier? It could respond
with a Content-Location where a PUT can be applied...

//Stefan

---

From: "Eric Sedlar" <[email-masked]>
Date: Fri, 22 Mar 2002 10:35:59 -0800

EDIT is the same thing as GETSRC/Translate.

--Eric