Re: Limiting the scope of an untagged If Header production (was: RE: If Header: evaluation of all assertions)

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