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

Jamie Lokier schrieb:
> 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.

As far as I can tell, proxies are not allowed to use the entity sent 
with PUT for updating the cache:

"If the request passes through a cache and the Request-URI identifies 
one or more currently cached entities, those entries SHOULD be treated 
as stale. Responses to this method are not cacheable." 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.6.p.2>).

> 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.

No, they will do exactly the right thing, as long as the client complies 
to RFC2616 (remember that it says that the ETag is for the stored 
entity, not the submitted one).

> 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.

It could do that, but I don't think it's necessary for correctly working 
clients.

>>>> 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.

Correct. And again; returning 205 upon PUT violates a SHOULD-level 
requirement:

"If an existing resource is modified, either the 200 (OK) or 204 (No 
Content) response codes SHOULD be sent to indicate successful completion 
of the request." 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.6.p.1>).

Best regards, Julian

Received on Thursday, 14 September 2006 11:37:40 UTC