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

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

That wouldn't always be a problem. There are lot's of scenarios where it 
would be ok to do that, as outlined in 
<http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-01.html#rfc.section.A.1>.

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

That would defeat some uses cases which (IMHO) are legal as per RFC2616 
(where octet-by-octet identity isn't required).

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

I know these servers exists and are deployed, because I wrote one of 
them :-).

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

As far as I can tell, the interop problem already is there (that's why I 
wrote the draft suggesting an approach that I *think* is faithful to 
RFC2616 and resolves the problem for new clients and servers, as 
discussed in XCAP and CalDAV).

Best regards, Julian

Received on Wednesday, 13 September 2006 15:55:33 UTC