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

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

Yes. And I agree that it may be written only with GET in mind. The 
problem here is that we don't know, and that it seems to be extremely 
hard to get consensus for a change. Thus, my attempt to (a) do apply 
minimal fixes to RFC2616 (to be acceptable by "most"), and (b) add an 
extension that is a simple as possible (to prevent bikeshed discussions).

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

Clients that cache the entity that was PUT today already will have 
potential interop problems with servers that rewrite content. There's no 
way to undo that damage. My draft just proposes a hopefully clean 
solution for future servers/client without breaking anything that was 
compliant before.

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

My impression is that caching in HTTP is optimized for read access. 
Anyway, the proposed header would enable that kind of cache optimization 
as well.

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

I think it is cache validation. This is the terminology used in RFC2616, 
whether the cache is in the client or in an intermediary.

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

I absolutely agree that there are other ways to achieve the stated goal. 
The problem is that the more changes you need to make to RFC2616, the 
less likely it is to get consensus. At least I think so.

Best regards, Julian

Received on Thursday, 14 September 2006 14:33:03 UTC