Re: i22: ETags on PUT responses

Henrik Nordstrom wrote:
> On lör, 2008-01-05 at 22:55 +0100, Werner Baumann wrote:
> 
>> When a server changes the body submitted in the PUT-request, it MUST NOT 
>> send an Etag-header in response, unless it knows that the client is 
>> aware of this changes and can handle them.
> 
> I don't agree here. Why do you see this as such big problem?
> 
> I am missing a usecase where this really causes a problem. All I see is
> plenty of usecases there not sending the ETag would be a major problem.
> 
The use case:
A caching WebDAV-client, that has no special knowledge about the server, 
except that it complies to the standards.

The client uses PUT to store a file on server and holds its own copy in 
the cache. It gets a strong etag in response from the server and 
associates it with the cached file. The client now relies, that it can 
use the cached file as if it was retrieved from the server via GET, for 
any practical purpose, without causing confusion or damaging data integrity.

If the client can rely on this, the server SHOULD send the etag. This 
will be an enhancement over the current situation. If the client cannot 
rely on this, the server MUST NOT send an etag, because the client's use 
of the cached file might cause confusion and data loss.

Examples besides delete:
- may the client display the stored file to the user, or will the user 
be confused, when direct access to the server shows different content?

- may the client edit the cached file and then upload it with a 
conditional PUT, using that etag?

- strong validators allow range-requests, even for PUT. Will this work?

Take examples A.3, A.4 in 
<http://greenbytes.de/tech/webdav/draft-reschke-http-etag-on-write-08.html>, 
where a server inserts content. Will it work, when the client inserts 
the same content into the cached copy and then does a conditional PUT, 
or will this end up in inserting the same content twice? If it works, 
the etag is an improvement, if not it causes data corruption.

What I am missing in this statement from Julian
 > - the presence of E in Rs does not necessarily imply that the body
     sent with PUT was stored octet-by-octet
is the guarantee, that the cached body is equal to what the server 
stores for any practical use.

I am maintaining a caching WebDAV-file-system (davfs2), that presents 
WebDAV-resources to none-webdav-aware applications as a local file 
system. What would the responsible behaviour of davfs2 be, when it gets 
an etag in response to a PUT, but has no guarantee, that the cached body 
is identical to the server version for any practical use? Shall it 
present the cached body to the application and risk data corruption? It 
must throw away the cached body and use GET (unconditional) to get the 
real thing.

At the moment, davfs2 is not that responsible for the sake of 
efficiency. But I would be very glad to get a reliable strong etag in 
the PUT-response. An unreliable etag would make things worse.

Werner

Received on Sunday, 6 January 2008 12:38:55 UTC