Re: Etag-on-write, 2nd attempt (== IETF draft 01)

Yves Lafon wrote:
> Clients have local caches, but it doesn't really matter, as having the 
> modified copy or the original one won't trigger an extra rewrite (ie: the 
> cvs version is not changed) in case of a subsequent PUT without any other 
> modifications, so per rfc2616,13.3.3, it is indeed a strong validator.

Firstly, what about _other_ clients using the same intermediate proxy
cache.  They'll see the PUT entity without modifications too.
Which may be fine, or it may be an unintended side effect.

Secondly, byte-range requests to refresh partially cached entities.
Those are allowed with a strong Etag (not a weak one), and they'll do
the wrong thing unless the server simply refuses them.

So a server which behaves this way should refuse byte range requests
when sent an "If-Match" with an Etag corresponding to an entity that
it rewrote, at least if the rewriting would clash with the byte ranges.

> >>Would it be OK for a server to return a 205 Reset Content with the Etag ?
> >>That way the client would know that a refetch is in order.
> >
> >That seems good to me so far.
> 
> Of course the issue is already deployed software, but every new way of 
> handling this issue won't solve the way they behave.
> It would be interesting to get the number of clients implementing 205.

In RFC 2616, 10.2.6 205 Reset Content, it says nothing about telling
the client to refetch the content.

Only things about document views and forms.

So even if there are clients which implement 205, there's no reason to
believe it would have the effect desired here.

-- Jamie

Received on Thursday, 14 September 2006 11:26:48 UTC