Subject: Re: WebDAV and Dynamic Content

From: Jim Whitehead <[email-masked]>
Date: Mon, 22 Nov 1999 10:57:58 -0800

Accidentally caught by the spam filter.  I've send in a request to have
Brett's email address added to the accept2 list for the WebDAV mailing list.

- Jim

-----Original Message-----
From: Brett McCormick [mailto:[email-masked]]
Sent: Sunday, November 21, 1999 5:52 PM
To: [email-masked]
Cc: Serge Knystautas; [email-masked]
Subject: [Moderator Action] Re: WebDAV and Dynamic Content

On Sunday, 21 November 1999, at 18:15:17, [email-masked] wrote:

> Serge.  I think we all want to see WebDAV support dynamic resources.
> And I think a few folks would say we already do.  I don't quite agree.
> I think we haven't really flushed them out well enough to be
> fully interoperabile.

I guess I haven't heard any reasons why the current scheme wouldn't
satisfy your requirements in a fully interoperable way.

I feel strongly that the webdav spec should not provide a facility for
obtaining the source content using the actual uri of the output
resource.  I feel that this extra mechanism is non interoperable.  The
DAV server may not even be able to fufill the request for the
unprocessed source, and the client must then fall back to the existing
mechanism.

It isn't functionality that is extensible enough for our needs
(assumes one source document) nor can it be uniformly provided across
DAV server implementations.

--brett

---

From: "Sean Lyndersay (Exchange)" <[email-masked]>
Date: Mon, 22 Nov 1999 16:33:05 -0800

Believe it or not, caching was considered when deciding on this
implementation.

Bascially, we do not allow public caching of dynamic data. To this end, we
place a "Cache-control: private" header on responses from dynamic resources.
Since most of the resources in the Exchange WebStore require authentication
to access, this doesn't make much difference -- we wouldn't want a public
cache caching it anyway. 

An application that does use the translate header will be able to cache
intelligently. This is approximately analogous to the way that an
application that uses one of the Accept headers must cache carefully with
respect to that header, but may ignore the others. An application (like a
browser) that is unaware of the translate header will not have any need to
worry about it since it will only ever see the one view of it.

Our concerns with the DAV:source property are basically administrative ones.
Since we, by design, have no differentiation between our URI namespace and
the contents of the store (i.e. a one-to-one mapping between URIs and items
in the store), this makes it extremely tricky to design an automatic
mechanism whereby each dynamic resource has a corresponding source resource.
In an environment where one desires to give as much freedom as possible to
the Administrator, it is difficult to mandate that the administrator must
essentially reserve some namespace (be it an additional virtual server, or
special URIs for each resource) for accessing source files. 

Sean

-----Original Message-----
From: Roy T. Fielding [mailto:[email-masked]]
Sent: Friday, November 19, 1999 10:35 PM
To: Sean Lyndersay (Exchange)
Cc: [email-masked]
Subject: 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. 

Well, congratulations, you chose the worst possible design choice.
By using a header field, you have excessively complicated the caching 
algorithm for all resources on your server.  If it isn't sending
"Vary: Translate" on every response, your server is not HTTP/1.1 compliant.

Next time, use a "source" property that contains a list of URI that
make up the sources for a particular resource.  Authoring requests are
of negligible significance for round-trip latency concerns, so spend
the round-trip where it has the least performance impact rather than
constipating the normal operation of your server.

....Roy