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

Jamie Lokier schrieb:
> The usage in that article should use a weak Etag, not a strong one.

<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.13.3.3> 
disallows usage of weak validators for anything except GET without 
byte-range, so it can't be used with PUT:

"Clients MAY issue simple (non-subrange) GET requests with either weak 
validators or strong validators. Clients MUST NOT use weak validators in 
other forms of request."

See also <http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.24>:

"A server MUST use the strong comparison function (see Section 13.3.3) 
to compare the entity tags in If-Match."

>>From the article:
> 
>     Note that the only problem here is that the client doesn't have an
>     exact copy of the entity it's editing. However, from the server's
>     point of view this is entirely irrelevant, because the "Revision"
>     keyword will be automatically updated upon every write anyway.
> 
> Think about what happens if the client were to do a byte-range GET to
> get part of the entity at this point (e.g. because it's editing a
> large entity, and decides to discard _part_ of it from its cache).
> Because of the substitution at the server, the byte ranges won't match
> and the file being edited will get really messed up.

Well, the draft also says that clients MUST NOT assume octet-by-octet 
identity unless the server indicates this using the "Entity-Transform" 
header. As far as I can tell, this is backwards compatible with RFC2616.

> Also, think about what happens if the user _wants_ to view the actual
> content at the server including substitutions made by the sever.
> Either they won't be able to, as intermediate proxy caches will
> continue serving the entity sent by PUT, no matter what client they're
> using (or even multiple clients).  Or they can use a client which
> disables proxy caching entirely even when that is unnecessary.

My interpretation is that a cache updates it's cache entry with the 
content sent with PUT would be buggy. See 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.6>:

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

> This is why the usage in
>     <http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-01.html#rfc.section.A.1>
> should use a weak Etag.

Nope :-)

>>> 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).
> 
> Where octet-by-octet identity isn't required, that's what _weak_ Etags
> (beginning with "W/") are for.  It's ok to send those in a PUT
> response without confusing clients.  Or at least, any clients which
> treat weak Etags as though they were strong deserve to be confused, as
> it's been in the spec forever.

See above. RFC2616 doesn't allow weak etags for cache validation in 
write operations.

 > ...

Best regards, Julian

Received on Thursday, 14 September 2006 10:42:09 UTC