RE: Summary of ETag related issues in RFC2518bis

I strongly agree with Jim's use case and conclusion.  That's the key issue: the client shouldn't have to poll to wait for the etag to stabilize.

    dan

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org 
> [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Jim Whitehead
> Sent: Monday, December 19, 2005 18:16
> To: Wilfredo Sánchez Vega
> Cc: Julian Reschke; WebDav WG
> Subject: Re: Summary of ETag related issues in RFC2518bis
> 
> 
> If I'm a client that has an exclusive write lock, then if I 
> PUT to that resource, the stored entity should not be 
> modified by anyone other than the server. In this case, which 
> is the most common one for DAV-based editing, it's still very 
> useful for the client to receive the final etag value in the 
> response to PUT. Why? It saves the client from having to poll 
> an uncertain number of times before it receives the final, 
> stable etag value.
> 
> I still feel that R2 is required.
> 
> - Jim
> 
> On Dec 19, 2005, at 5:13 PM, Wilfredo Sánchez Vega wrote:
> 
> >
> >   There is no such thing as a final etag value.  Why 
> pretend there is?  
> > The tag could change for any number of reasons, including someone 
> > coming along and changing the content right after your PUT.
> >
> >   Absent some reliable notification mechanism, there is no 
> way to know 
> > that your locally cached copy is what's presently on the server, 
> > regardless of whether the server gives you a stable etag in the PUT 
> > response or not.  So this requirement doesn't get you what you are 
> > wishing for.
> >
> > 	-wsv
> >
> >
> > On Dec 19, 2005, at 1:20 PM, Jim Whitehead wrote:
> >
> >> R2) Require servers to return entity tags for PUT requests
> >>
> >> Required. Or, put another way, what clients need is the ability to 
> >> know the final value of the etag assigned to the server's 
> >> representation of the resource created by a successful 
> PUT. It seems 
> >> that the best way to do this is to have the server respond 
> with that 
> >> Etag in the PUT response. What might also work is for 
> there to be a 
> >> guarantee that this final etag will be available within a 
> given time 
> >> period, and hence clients will only need to perform a single 
> >> follow-on request to get this etag. However, protocol requirements 
> >> involving timing are usually very hard to get right -- it's not my 
> >> first choice. That's why I think returning the etag in the PUT 
> >> response is the best way to communicate this final etag value.
> >
> 
> 
>

Received on Tuesday, 20 December 2005 02:24:15 UTC