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

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

    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.

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

Received on Wednesday, 13 September 2006 01:02:42 UTC