- From: Stefan Eissing <stefan.eissing@greenbytes.de>
- Date: Mon, 14 Oct 2002 19:20:50 +0200
- To: "Lisa Dusseault" <lisa@xythos.com>
- Cc: "'Clemm, Geoff'" <gclemm@rational.com>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
Lisa, good idea. However this does not cover the case where the collection has a shallow, exclusive lock. I don't know now relevant/important this case is. Our client does, for example, not use the untagged production, exactly because server implementation differ most on this feature. //Stefan Am Montag, 14.10.02, um 19:09 Uhr (Europe/Berlin) schrieb Lisa Dusseault: > That wouldn't necessarily break, depending on what you're checking. I > assume you're checking a lock token because etags aren't defined for > collections. > > E.g we could also make RFC2518bis clear on whether you can apply a lock > token (for a depth infinity lock) to any URL included in the scope of > the lock. If we require servers to accept this as a valid use of the > lock token, then the untagged production applying to the Request-URI > still works in this case. > > lisa > >> -----Original Message----- >> From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] >> On Behalf Of Stefan Eissing >> Sent: Monday, October 14, 2002 1:44 AM >> To: Clemm, Geoff >> Cc: 'Webdav WG' >> Subject: Re: Limiting the scope of an untagged If Header production > (was: >> RE: If Header: evaluation of all assertions) >> >> >> Another possible "breakage" is use of the untagged if header for >> PUT on unmapped resources. At least our server uses then the >> untagged production to check the parent resource. >> >> //Stefan >> >> Am Sonntag, 13.10.02, um 19:36 Uhr (Europe/Berlin) schrieb Clemm, > Geoff: >> >>> I am somewhat concerned about the effect of this change on >>> the semantics of existing clients. >>> >>> For example, do any clients today submit the etag of both the source >>> and the destination resource of a MOVE in an untagged If production? >>> If so, this change would remove the etag check on the Destination, >>> and thereby break the overwrite protection for that request. >>> >>> But if we won't be breaking existing clients, I fully support this >>> change, since it simplifies and clarifies the semantics of the >>> If header. >>> >>> Cheers, >>> Geoff >>> >>> -----Original Message----- >>> From: Lisa Dusseault [mailto:lisa@xythos.com] >>> >>> Also, I would clarify what the untagged if production refers to, and > it >>> should probably refer only to the resource named in the Request-URI. >>> >> >
Received on Monday, 14 October 2002 13:21:28 UTC