W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2005

RE: Summary of ETag related issues in RFC2518bis

From: Dan Brotsky <dbrotsky@adobe.com>
Date: Tue, 20 Dec 2005 21:51:35 -0800
Message-ID: <E1F796B37FB8544FA09F6258E7CED3BB4B9349@namail3.corp.adobe.com>
To: "Julian Reschke" <julian.reschke@gmx.de>, "Jim Whitehead" <ejw@soe.ucsc.edu>
Cc: Wilfredo Sánchez Vega <wsanchez@wsanchez.net>, "WebDav WG" <w3c-dist-auth@w3.org>

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

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.

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.

Received on Wednesday, 21 December 2005 05:51:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:34 UTC