Re: WebDAV and Dynamic Content

I'm not exactly sure why we're having this thread, there is an
established mechanism for this in the webdav spec.  But, in my view:

A URI refers to a distinct resource.  A URI cannot simultaneously
refer to the source and output of a dynamic resource.  That's what the
source element is for.

To say that you should be able to access the source *and* output of a
dynamic resource is to say that one uri does not equal another, when
that is clearly not true.

The source(s) and output are different resources.  Therefore, access
to them should be via distinct URIs.

More comments below...

On Saturday, 20 November 1999, at 02:20:09, Serge Knystautas wrote:

> I'm very interested in better understanding the pros and cons of using
> the same URI for viewing dynamic content, and editing it's source.  For
> Perl scripts, TCL scripts, JSPs, ASPs, and eventually XML documents
> using XSLT and more advanced stuff, I would think WebDAV could really
> benefit from consideration of this usage.
> 
> Comments below...
> 
> "Roy T. Fielding" wrote:
> > >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.
> 
> I would prefer to not have to educate each human author (probably
> frequently different for each web server) to be able to use WebDAV in
> this context.  Surely the software and protocol could realize and
> indicate when it wants processed content and when it wants source
> content.

The education of each author is already required.  You have to tell
them that what they need to edit is at /foo/bar/baz/, and you can also
tell them at the same time that to access the source they should use
/source/foo/bar/baz.

The client doesn't get to choose if they get processed content or not,
they get what they requested: the content of the given URI.


> > >...
> > >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.
> 
> Again, <gorilla voice>Me see /folder/foo.bar.  Me want edit
> /folder/foo.bar.  Why me must edit /folder/foo.bars?</gorilla voice>

That's why webdav compliant editors/publishers should pay attention to
the established mechanism for resolving this problem (?).

> 
> > >1. Configure the WebDAV server to not process any dynamic content. Require
> > 
> > Not an option.
> 
> Um, could you complete this thought and explain why you do not consider
> this an adequate option?

It's a little hard to sum up.  In has to do with the fact that:

1) DAV functionality is often an add-on to existing, functional http servers.
2) the dav implementation more than likely has no control over whether other
   parts of the http server perform their requested function
3) the dav implementation will also not likely know all the actual
   source(s) of the dynamic content

For instance:

I have an apache module which dynamically generates GIF files based on
the request URI.  How do you suggest adding functionality to DAV
(mod_dav, in this case) that would prevent me from returning the
dynamic content and instead return the "source" of the dynamic content.

I do not know how mod_dav would behave if I tried to PUT to one of the
urls, I would hope that it would complain appropriately.  I may try
this.

> 
> > >- user has to remember two URLs
> > 
> > Or do a PROPFIND for the source URLs (there can be many more than one).
> > 
> 
> I think of a user as a human (who must remember).  Then there's the
> client software that does a PROPFIND.  I'm not sure how your comment
> relates to his point.  Could you expand on it?

His point is that there is already a way of doing all this, why not
use it?

> > >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.
> 
> Well, I need to read up on WebDAV-related caching and multi-source
> resources, but could you expand on how this doesn't work and how caching
> is bolloxed up?

Ok.  You request http://foo.com/bar/.  Your browser is configured to
use a proxy, so it requests it.  You then attempt to publish to this
url.  Your DAV client also makes a GET request to the same URI, except
this time attaching the appropriate proprietary header.  The proxy has
no idea what that header means, and of course returns the cached
dynamic content of the URI, which you edit and accidentally publish to
the source.

It all comes down to the fact that you can't use one URI to refer to
two separate resources.

--brett

Received on Saturday, 20 November 1999 03:32:34 UTC