W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: i22: ETags on PUT responses

From: Mark Nottingham <mnot@mnot.net>
Date: Mon, 7 Jan 2008 09:35:54 +1100
Cc: Henrik Nordstrom <henrik@henriknordstrom.net>, ietf-http-wg@w3.org
Message-Id: <06DB9E67-9C0D-4C5E-AB54-CDDC7895BB0F@mnot.net>
To: Werner Baumann <werner.baumann@onlinehome.de>

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  

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

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:44 UTC