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

Julian Reschke wrote:
> <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."

For If-Match in GET, that makes sense.

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

Dubious, but:

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

I see!

This model is inconsistent, unfortunately.  While the above statement
applies to proxy caches, it's deliberately not being applied to the
"cached data model" inside an editing client application, for example.
While they are different things, they are conceptually very similar.

The conceptual similarity is most apparent if your editor is a web or
WebDAV browser, and you click "refresh" and "view source" hoping to
see what other people see... and find that it's different.  The
browser's internal cache may cache what it PUT, if the assumptions
being discussed in this thread about Etag were (incorrectly) assumed.

It's also quite unfortunate that PUT entities cannot be cached by
proxies (and other transparent caches), for bandwidth reasons.  If, in
the next specification, we were to say that PUT response Etags allow
the PUT entity to be stored in the cache (otherwise, the default is
that it's not allowed), that would be nice.

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

That's not cache validation.  It's update validation: a different
thing, whose semantics you are presumably free to define at this
point?

But:

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

It does seem as though this condition on If-Match ought to be relaxed
for PUT operations to server applications which can define "weak" to
mean "sufficiently good for safe updates".

-- Jamie

Received on Thursday, 14 September 2006 14:18:14 UTC