RE: WebDAV and Dynamic Content

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:fielding@kiwi.ICS.UCI.EDU]
Sent: Friday, November 19, 1999 10:35 PM
To: Sean Lyndersay (Exchange)
Cc: w3c-dist-auth@w3.org
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

Received on Monday, 22 November 1999 23:37:39 UTC