[Bug 13] new ETag requirements

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=13

julian.reschke@greenbytes.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|julian.reschke@greenbytes.de|elias@cse.ucsc.edu
             Status|ASSIGNED                    |NEW



------- Additional Comments From julian.reschke@greenbytes.de  2006-01-29 06:26 -------
OK, I firmly believe that the right thing to do for RFC2518bis is NOT to
introduce any new requirements for ETag behaviour upon PUT, and let another
document define this. If we can get this document out in time, I'd be ok to let
RFC2518bis refer to it.

In the meantime I would appreciate that this stuff is taken out. Proposed
changes in
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.issue.bz013>
and below:

Section 8.5., para. 1:
OLD:

    HTTP 1.1 recommends the use of the ETag header in responses to GET
    and PUT requests.  Correct use of ETags is even more important in a
    distributed authoring environment, because ETags are necessary along
    with locks to avoid the lost-update problem.  A client might fail to
    renew a lock, for example when the lock times out and the client is
    accidentally offline or in the middle of a long upload.  When a
    client fails to renew the lock, it's quite possible the resource can
    still be relocked and the user can go on editing, as long as no
    changes were made in the meantime.  ETags are required for the client
    to be able to distinguish this case.  Otherwise, the client is forced
    to ask the user whether to overwrite the resource on the server
    without even being able to tell the user whether it has changed.
    Timestamps do not solve this problem nearly as well as ETags.

NEW:

    HTTP 1.1 recommends the use of the ETag header in responses to GET.
    Correct use of ETags is even more important in a distributed
    authoring environment, because ETags are necessary along with locks
    to avoid the lost-update problem.  A client might fail to renew a
    lock, for example when the lock times out and the client is
    accidentally offline or in the middle of a long upload.  When a
    client fails to renew the lock, it's quite possible the resource can
    still be relocked and the user can go on editing, as long as no
    changes were made in the meantime.  ETags are required for the client
    to be able to distinguish this case.  Otherwise, the client is forced
    to ask the user whether to overwrite the resource on the server
    without even being able to tell the user whether it has changed.
    Timestamps do not solve this problem nearly as well as ETags.


Section 8.5., para. 2:
OLD:

    WebDAV servers SHOULD support strong ETags for all resources that may
    be PUT.  If ETags are supported for a resource, the server MUST
    return the ETag header in all PUT and GET responses to that resource.

NEW:

    WebDAV servers SHOULD support strong ETags for all resources that may
    be PUT.  If ETags are supported for a resource, the server MUST
    return the ETag header in all GET responses to that resource.


Section 15.6., para. 6:
OLD:

    Description:  The getetag property MUST be defined on any DAV
       compliant resource that returns the Etag header.  Refer to RFC2616
       for a complete definition of the semantics of an ETag.  Note that
       changes in properties or lock state MUST not cause a resource's
       ETag to change.

NEW:

    Description:  The getetag property MUST be defined on any DAV
       compliant resource that returns the Etag header.  Refer to Section
       3.11 of [RFC2616] for a complete definition of the semantics of an
       ETag.  See Section 8.5 for further discussions of ETag usage in
       WebDAV.





------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

Received on Sunday, 29 January 2006 14:26:29 UTC