- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 7 Jan 2008 09:35:54 +1100
- To: Werner Baumann <werner.baumann@onlinehome.de>
- Cc: Henrik Nordstrom <henrik@henriknordstrom.net>, ietf-http-wg@w3.org
Upon what basis does the client cache the representation it sent, if it's just working within the standards? I.e., how does it derive a freshness lifetime? At best, it seems to me that it could cache what it sent as stale, but it'd need to validate the ETag it was given before serving it as fresh. I suppose it could compute a synthetic Last-Modified and base heuristic freshness from that, but most sane heuristics I've seen treat something that was just modified as fairly suspect of being changed again. Of course, it could be operating as an offline cache, in which case it wouldn't need to validate, but in doing so it'd have to be willing to take some variation from what the server might actually send back to a new GET (sending Warning, etc.) -- which falls nicely within this scenario. On 06/01/2008, at 11:38 PM, Werner Baumann wrote: > The use case: > A caching WebDAV-client, that has no special knowledge about the > server, except that it complies to the standards. > > The client uses PUT to store a file on server and holds its own copy > in the cache. It gets a strong etag in response from the server and > associates it with the cached file. The client now relies, that it > can use the cached file as if it was retrieved from the server via > GET, for any practical purpose, without causing confusion or > damaging data integrity -- Mark Nottingham http://www.mnot.net/
Received on Sunday, 6 January 2008 22:36:15 UTC