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

On Wed, 13 Sep 2006, Jamie Lokier wrote:

>> On Sep 13, 2006, at 24:55, Lisa Dusseault wrote:
>>> It's technically correct to say that servers are allowed to rewrite
>>> content.  However, existing deployed offline-cache clients assume
>>> that they do not.

Well, I have a server that does exactly that, as CVS is expanding keywords 
like $Id$ on commit.

>> To the client it doesn't(/shouldn't) matter whether the server
>> rewrote the content or whether another client did? They need to deal
>> with the situation anyway? It changed and they need to update the
>> data. The earlier they get changes by "others" the better, ideally in
>> the PUT response (yes, it doesn't even need to be the case that the
>> server modified the resource if the etag changes, it could have been
>> a different client).
>
> Isn't this the problem scenario:
>
>    1. An existing deployed client (or cache, it doesn't matter) sends PUT.
>
>    2. The server sends 200 OK with Etag back in response.

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.

>    3. Later, same client sends GET with If-None-Match and the Etag it
>       received in step 2.
>
>    4. The server sends 304 Not Modified, because the Etag matches
>       what it sent before.
>
>    5. The existing deployed client erroneously* uses the entity it
>       sent in step 1.  (If it's a proxy cache, it serves that entity
>       to its clients).
>
> * Erroneous only if the server is allowed to modify the entity it
> receives in PUT _and_ respond with an Etag which matches that modified
> entity.

What is the scope of the "modification" here? 13.3.3 says that the concept 
of a modification is up to the server.

> To avoid such errors _in new deployments_ which are intended to
> interoperate with existing ones, one (or both) of the following are
> suitable:
>
>   1. If a server sends a strong Etag in a PUT response, future
>      conditional requests using that Etag will only match if the
>      entity has not changed at all.  (If a server sends a weak Etag
>      in a PUT response, future conditional requests using that Etag
>      will only match if the entity has not changed according to the
>      meaning of "weak".)
>
>   2. If a client receives a strong Etag in a PUT response, it should
>      ignore it.
>
> If there are already deployed clients which don't satisfy requirement
> 2, then it would be appropriate to insist on requirement 1 in future
> specifications, so that future deployments interoperate with existing
> ones.
>
> If there are already deployed servers which don't satisfy requirement
> 1, then it would be appropriate to insist on requirement 2 in future
> specifications, so that future deployments interoperate with existing
> ones.
>
> But if there are _both_ deployed clients and servers which don't
> satisfy those requirements out there, those will already fail to
> interoperate with each other.  There is no specification which can fix
> this.  However, the choice of 1, 2 or both will affect
> interoperability of future deployments with the existing onesa.
>
> -- Jamie
>

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

Received on Wednesday, 13 September 2006 12:47:17 UTC