David Durand writes: >So if the Entity tag is the same, the document is byte-for-byte identitical. >If the the Entity tag is "Weak", then it may not be byte-for-byte identical, >if the tags are the same, but the server is saying that it doesn't care, >and caching would still be acceptable. I didn't have a chance to check out >how this affects content-type negotiation, but I got the impression that each >type would have its own entity tag. > > It seems to me that a versioning system provides the right information to >calculate this stuff correctly (and is under obligation to do so), but that >ETags don't solve many of our problems for us (though they do provide a nice >way to check if the "current version" has changed or not). My question (from San Mateo) was whether the notion of "current version" for cacheability is so different from the notion of "current version" for versioning that we need an additional layer beyond the ETags. (and in the rather narrow scope of preventing conflicting overwrites) I imagine the most common system would be a "major/minor" sort of thing, where minor revisions were bumped on every change (and hence equivalent to strong tags), and major revisions were bumped when the content had changed to the point where the provider no longer wished it to be cached (and hence equivalent to weak tags). I admit this is a very naive view of versioning, but I'm not sure that it helps to add complexity. Can anyone post a scenario where it is important to decouple cacheability from the version id? -Dave