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

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:10:27 UTC