On Tue, 2008-03-18 at 09:44 +1100, Mark Nottingham wrote:
> This crossed my mind as well... Weak ETags are in use today, but can
> we find a situation where they're actually improving things, and
> getting interoperability?
There is no real interoperability problem with weak etags today, other
than some servers not implementing weak matches in their default
filesystem based conditional processing.
Clients behave well, and servers using (not only sending) weak etags can
make good use of them.
The only real problem is this discussion, of which maybe 80% is fud from
not understanding how servers use weak etags today and people drawing
far going conclusions from just a small part of the picture, 10%
misunderstandings of what weak etags may be used for, 5% total confusion
and 5% actual discussion moving forward.
Personally I wish we could extend weak conditionals to be allowed in
If-Match processing for most methods which would make the protocol more
complete for the situations where one need (or wants) to use weak etags,
but thats outside our scope.
For whats within our scope the existing definition of weak etags and
weak conditionals is very sane, if one ignores the confusion about what
is actually meant by "semantic equivalent" which is a product of the
language used in the descriptive text outside of the actual definitions
combined with those 10% who wants to use etags for more than they are
(part of that also visible in the meaning of ETag in response to PUT
discussion).
Getting rid of the "semantic equivalence" mistakes, sticking to "no
significant semantic difference in point of view of the server" whould
help a lot in keeping people on track on what a weak etag is and meant
to be used for. Together with a reminder that the only 2616 operation
allowing a weak condition is GET If-None-Match, which for most uses of
weak etag is quite sufficient, but falls short for extensions like
WebDAV or CalDAV who have additional needs (CalDAV in particular as it's
application scope makes strong ETags quite unsuited, with a lot of not
fully deterministic server-side processing going on affecting the octet
equivalence)
Regards
Henrik