Re: Summary of ETag related issues in RFC2518bis

Dan Brotsky wrote:
> ...
> In no case does a client ever assume that "the text it sent with the PUT
> is what would be retrieved by the GET."  That's not what the etag is
> for.  The etag is to reassure the client that the value on the server
> *has not changed since the PUT completed*.  No guarantees are issued
> that the value doesn't change as part of the PUT; that would be a part
> of the PUT semantics for that server and are outside the scope of
> WebDAV.
> ...

Thanks, Dan :-)

So let's look at what clients are interested in again:

- they want to avoid fetching an ETag after PUT,

- in some cases, they want to be able to find out whether the server 
stored exactly what they sent,

- if they interleave PUT and PROPPATCH, they want their ETags to 
continue to work.

I believe all of these things can be accomplish by protocol extensions, 
and I'll be happy to spec them out. On the other hand, I don't think it 
would be a good idea to rush them into RFC2518bis, which was supposed to 
be finished around this time of year (if I may remember).

Best regards, Julian

Received on Tuesday, 20 December 2005 09:18:38 UTC