Subject: Re: ETags, next call, was: Notes on call from today ...

From: Cullen Jennings <[email-masked]>
Date: Tue, 13 Dec 2005 14:28:33 -0800

I have still been looking for an answer on a question I asked long ago on
this. If a client needs a strong ETag, and it gets a weak ETag, should the
client poll the server until it gets a strong ETag? This seems to be the
recommendation but no one seem to say "yes" or "no" to this?

On 11/30/05 2:53 AM, "Julian Reschke" <[email-masked]> wrote:

> Lisa Dusseault wrote:
>> On Nov 29, 2005, at 12:07 PM, Julian Reschke wrote:
>> 
>>> 
>>> It seems that you have a very specific authoring scenario in mind,
>>> which you'd like to be simpler to support in a client. How about
>>> summarizing the *precise* requirements first, then think about the
>>> right technical approach, and only then discuss a way what to do in
>>> the spec? Yes, that's more work to do then simply stating "Strong
>>> ETags are now required", but it's the better approach nevertheless.
>>> 
>>> 
>> 
>> First, before discussing the precise requirements I have in mind, I'd
>> like to remind you that the "Strong ETags" proposal didn't come from me
>> alone, I'm not the only one with requirements.  After the 2002 interop
>> where this was first discussed, we had a bunch of list discussion about
>> this in late 2002, e.g. Dan Brotsky's email of Oct 16 and yours of Nov
> 
> I guess it would be good if people would just re-read what was discussed
> back then (Dan: 
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0119.html>,
> myself replying: 
> <http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0141.html>).
> 
> If there was consensus back then, it was for:
> 
> 1) ETags are good. Strong ETags are better. Optimally, PUT returns a
> strong Etag.
> 
> 2) Server support for ETags must be consistent (that is, DAV:getetag and
> ETag response header should agree)
> 
> Re 1) I don't think there's any disagreement here. The question is how
> to achieve it. Putting SHOULD- or MUST-level requirements into the spec
> without understanding why servers may not be doing it already is IMHO
> the wrong approach.
> 
> Re 2) Of course. If that needs clarification in the spec, let's do it.
> 
>> 28. You were the one who pointed out that solving the problem we were
>> discussing required strong ETags, not weak ETags.
> 
> What I pointed out was that the requirement you want to make makes
> Apache/mod_dav non-compliant, as it returns weak ETags upon PUT.
> 
>> The requirements:
>>  - Clients must be able to interoperate against different server
>> implementations with great consistency.  That means that there should be
>> very few cases where clients need to determine what the server
>> implementation is or what features it supports, or how, before choosing
>> between alternative code paths.
> 
> Yes. It's good when this is the case. On the other hand, it's also good
> when servers can support WebDAV for a wide range of resource types, not
> just filesystem-like stores.
> 
>>  - Clients must be able to be confident, when doing a PUT, that they are
>> not overwriting another client's change -- that means that there must be
>> some way to compare the state of the resource to the state when it was
>> last retrieved.
> 
> ETags do that. If a server doesn't support ETags, the client always can
> refuse to update.
> 
> On the other hand, as Wilfredo just pointed out, filesystems do not have
> ETags either, and people just live with that (last update wins). So yes,
> it's nice if you can avoid it, but it's unclear why it needs to be a
> WebDAV requirement.
> 
>>  - Specifically, this must work for images, HTML pages, office
>> documents, etc -- without requiring any different behavior on the part
>> of a client.  It would be nice if the server didn't have to care what
>> kind of resource it had, as well.
> 
> So are you now requiring that a WebDAV server can store any type of
> binary content? What if it's a WebDAV connector on top of an XML database?
> 
>>  - It must be possible to write a generic library or remote file system,
>> such as WebDAV FS, Xythos WFC or Adobe's library -- one which
>> communicates with the WebDAV server on behalf of an application such as
>> Word or Photoshop, without requiring overly heavy integration between
>> the application and the library.
> 
> It's hard to judge what that actually means protocol-wise.
> 
>>  - Clients must be able to keep an offline store with content that's
>> fairly reliably consistent with what's on the server.  (One problem to
>> solve here is for the client to know whether it needs to download a
>> resource after a PUT)
> 
> As far as I can tell, the recent discussion on the HTTP mailing list
> shows that ETags do not help with that.
> 
>> I generated these rather off-the-cuff, but I believe that's a good start
>> at least.
> 
> Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 13 Dec 2005 23:30:32 +0100

> recommendation but no one seem to say "yes" or "no" to this?

The answer is "no", unless the client happens to know that it talks to a 
server that indeed upgrades the weak to a strong one later (which in 
general will not be the case).

Best regards, Julian

---

From: Geoffrey M Clemm <[email-masked]>
Date: Tue, 13 Dec 2005 17:34:43 -0500

+1 for "no".

---

From: Wilfredo Sánchez Vega <[email-masked]>
Date: Tue, 13 Dec 2005 15:09:40 -0800

Yeah, you have no way to know that you will ever get a strong ETag  
unless you are depending on a specific server implementation.

	-wsv

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 13 Dec 2005 16:21:03 -0800

> general will not be the case).

Ok - thanks - that helps me think about this.