Re: WebDAV and Dynamic Content

>Dynamic content presents two fundamental problems for a WebDAV server:
>1. How does the server distinguish between access to source and access to
>processed results

Different URI.

>2. How are resources made available to server-side extensions that access
>them through the file system

By authoring the server-side extension configuration (a different URI,
or maybe a property of the URI or the immediate collection, but most
definitely not part of the WebDAV standard).  In most cases this is
just automatic based on some characteristic (known to the human author)
of the source URI on that particular server's namespace.

>...
>For other resources, the dynamic content and the source have the SAME URL.

That is never true.  Do not equate filenames to resources.  Every filename
in Apache can correspond to many different resources, and many resources
have no corresponding filename.  The server just maps some imaginary
namespace onto the filename space.

>The current WebDAV doesn't provide any interoperable way to resolve this
>issue. However, advanced collections and binding does. Here is a list of
>possible solutions (assuming advanced collections), and their pros and
>cons:
>
>1. Configure the WebDAV server to not process any dynamic content. Require

Not an option.

>2. For every dynamic resource, create a binding from the dynamic resource
>to its source, and configure the server so that the URL for the source
>binding does not invoke dynamic content. For example, bind HelloWorld.jsps
>to HelloWorld.jsp and configure the server so that resources ending in
>.jsps are text/plain while resources ending in .jsp are processed Java
>Server Pages.

The answer.

>+ only need one server running
>+ no duplicate resources
>+ no need to copy, and therefore no possibility of forgetting and getting
>stale dynamic resources
>+ no publish step, the BIND only has to be done once.
>- have to do the BIND for each dynamic resource, but only once

The binding may be implicit based on the server's configuration.  The
server can tell you what the source URL is after the resource is created
(or, more likely, what the normal GET URL is after the source is PUT to
its own URL).

>- have to administer the server to not process some URLs (the ones bound to
>the dynamic resources for the purpose of accessing their source)

The server already does that.

>- user has to remember two URLs

Or do a PROPFIND for the source URLs (there can be many more than one).

>3. Extend WebDAV to include a Process-Source Boolean header. GET on a URL
>with Process-Source set to 'F' would return the dynamic content while 'T'
>would return the source. If the content is not dynamic, the header is
>effectively ignored as both 'T' and 'F' would have the same effect.
>+ only need one server
>+ no duplicate resources
>+ no copy and no stale dynamic resources
>+ no BIND step or publish
>+ no administration required to distinguish source and dynamic content URLs
>+ user only has to remember one URL
>- requires an extension/change to WebDAV
>- introduces another header

Absolutely not.  It doesn't work for multi-source resources and completely
bolloxes caching.

>4. Add a GETSOURCE method.
>+ no new header required
>+ user only has to remember one URL
>- another method that usually does the same thing as GET

A derived resource (the resource that you are calling dynamic) has by its
nature a set of URI that make up its source.  It is far more natural,
and much easier for the server, to treat a natural property of a resource
as a WebDAV property on a WebDAV resource.

>Allowing dynamic resource to access resources using the file system

This has no relevance to WebDAV, aside from the need for access control
to specify whether the user has the right to create resources that include
other resources on the server.

....Roy

Received on Saturday, 20 November 1999 01:56:48 UTC