W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1999

Re: WebDAV and Dynamic Content

From: Serge Knystautas <sergek@lokitech.com>
Date: Sat, 20 Nov 1999 02:20:09 -0500
Message-ID: <38364BA9.BE087017@lokitech.com>
To: "Roy T. Fielding" <fielding@kiwi.ICS.UCI.EDU>
CC: jamsden@us.ibm.com, w3c-dist-auth@w3.org
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

> >...
> >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>

> >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?

> >- 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?

> >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?

Serge Knystautas
Loki Technologies
Received on Saturday, 20 November 1999 02:25:06 UTC

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