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

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" <julian.reschke@gmx.de> 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

Received on Tuesday, 13 December 2005 22:28:57 UTC