- From: Werner Baumann <werner.baumann@onlinehome.de>
- Date: Sun, 06 Jan 2008 13:38:33 +0100
- To: Henrik Nordstrom <henrik@henriknordstrom.net>
- CC: ietf-http-wg@w3.org
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