RE: WebDAV and Dynamic Content

Funny you should bring this up. Exchange Server has had to deal with the
problem in our implementation and decided to solve it with a new header,
"Translate"  on GET requests, which takes the values "t" and "f" and
defaults to "t" if omitted. 

As defined, the translate header simply indicates if the Web Server should
perform any sort of "translation" on the file -- generally in the form of an
interpreter acting on it.

For instance, a GET with "translate: f" on a .asp file will return the
source of the file (assuming you have permission to access the source),
while a "translate: t" (or an omitted translate header) will return the file
after processing from the ASP interpreter. So a simple client (like a
browser) will get the intended result (the processed page), while a
DAV-aware editor can GET the source for editing. 

The header extends easily into several other scenarios that we come across.
It is basically the simplest and most easily implemented solution to what
can be a difficult problem. 

In answer to your concerns about "what if there are multiple sources" -- I'm
afraid I don't understand the issue. In situations I'm familiar with, if
there are multiple sources then they are "included" in some fashion into the
main source file -- which makes them separate files with separate URLs which
can be retrieved using the same method. There's no need to get more complex
than this. If it was a file system, you wouldn't expect your fopen()/fread()
calls to retrieve all included files as well. 

When our product cycle winds down a bit, we expect to publish this extension
as an I-D. 

Sean Lyndersay
Program Manager, WebDAV
Microsoft Exchange Server


> -----Original Message-----
> From: Brett McCormick [mailto:brett@mail.flyingcroc.net]
> Sent: Friday, November 19, 1999 11:09 AM
> To: jamsden@us.ibm.com
> Cc: w3c-dist-auth@w3.org
> Subject: Re: WebDAV and Dynamic Content
> 
> 
> On Tuesday, 16 November 1999, at 16:14:46, jamsden@us.ibm.com wrote:
> 
> > For many dynamic resources, the dynamic content and the 
> source resources
> > are different MIME types and have different URLs. For 
> example Java source
> > resources end in .java while binary executable resources 
> end in .class.
> > These resources present no problem because the client can 
> do a GET on the
> > source URL to get the source, and a GET on the separate 
> executable URL to
> > get the processed results. The DAV:src property on the 
> executable can be
> > used to get the source resource URL.
> 
> These would not be examples of dynamic resources.  Java source
> resources are manually compiled into class files.  These aren't being
> generated dynamically.
> 
> > For other resources, the dynamic content and the source 
> have the SAME URL.
> > For example, Java Server Pages, Active Server Pages, 
> server-side includes,
> > server-side scripting, etc. This presents a problem because 
> there's only
> > one method to get both, GET. The DAV:src property doesn't 
> help because it
> > has the same URL as the executable. And, there's no header 
> on GET that can
> > be used to distinguish source from dynamic results. We 
> could use the Accept
> > header to specify what MIME type is desired, and use that 
> to distinguish
> > source from dynamic results, but that might now work either 
> as they could
> > have the same MIME type, and the dynamic resource might 
> support multiple
> > MIME types.
> 
> This is normally how dynamic content works.  Input file->code->output.
> Sometimes the input file is the code, sometimes its the output,
> sometimes its a little bit of both.  Or there could be many input
> files, which is quite likely, or even multiple outputs.  What does DAV
> do with multipart content?
> 
> > 
> > The FrontPage extensions resolve this conflict by either 
> using a method
> > extension to get the source, or a new header. Could someone 
> supply the
> > details? They might be a useful model for how we should 
> extend WebDAV.
> 
> It sounds shortsighted, as there can be multiple sources.  Does the
> new method get all sources?  What about PUTing the source back to
> server?
> 
> --brett
>

Received on Friday, 19 November 1999 20:19:21 UTC