Re: Summary of ETag related issues in RFC2518bis

Dan Brotsky wrote:
>> Well. If the client has the lock, why would it need the ETag 
>> in the first place?
> 
> Because servers can still write files when they are locked, and because losing a lock doesn't mean that you don't have up-to-date content.

1) If a server changes the contents of the file, and the client updates 
it again, without resyncing, why would that be a problem? I would assume 
that after applying the server-rewrite functionality (keyword expansion, 
virus checking, script stripping, property inclusion into the 
resource....), the result will be the same in both cases.

2) I still think that losing a lock is an edge case that we don't need 
to optimize for.

> One of the primary uses, if not *the primary use*, of etags in a collaborative authoring environment is so clients can know whether or not they have current content.  When a client authors a file and places it on the server, it doesn't want to have to fetch the file again unless necessary, and it doesn't want to have to do more roundtrips before continuing with work on that and other files.

Yes.

> Let me ask the  converse question: If the server has the file, why can't it send the etag?  That's all the spec is saying it should do.

1) RFC2518 isn't saying it
2) RFC2616 doesn't say what that means (or if it does it's doing that in 
such a vague way that reasonable people disagreed about what it means)
3) The most widely deployed servers do not return an ETag (IIS 5.1, does 
anybody know about IIS 6), or return a weak ETag first

So this would be a normative change introducing a less-than-well-defined 
requirement, which doesn't even reflect what most servers do today.

So my proposal is to resolve 2) first, and then discuss an extension of 
RFC2518 that relies on it (conceivably containing other stuff like the 
requirement to store arbitrary dead properties and such). I really don't 
see how we can get this done in the time that has been allocated to us.

Best regards, Julian

Received on Thursday, 22 December 2005 06:32:54 UTC