- From: Lisa Dusseault <ldusseault@xythos.com>
- Date: Wed, 20 Mar 2002 13:12:11 -0800
- To: <w3c-dist-auth@w3.org>
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
Received on Wednesday, 20 March 2002 16:39:59 UTC