RE: RFC2518 LOCK Response Code

My vote would be that a 409 is the correct status code, and
that 8.10.7 should be updated to reflect this.  There will be
other reasons why you would get a 409 (perhaps access control
limitations), so this is just one of the reasons why you'd
get a 409.  I'd only return 207 when a Depth operation effectively
caused the method to be applied independently to all the members
of the collection, and this is not the case for a LOCK request,
where a single lock-token is allocated (whose scope is the whole
collection).

Cheers,
Geoff

-----Original Message-----
From: Hall, Shaun [mailto:Shaun.Hall@gbr.xerox.com]
Sent: Wednesday, December 06, 2000 4:31 AM
To: 'W3C WebDAV Mailing List'
Subject: RE: RFC2518 LOCK Response Code


Reposting as I've had no response to this.

Am I correct in my assumption i.e. does the spec need updating?

Regards

Shaun Hall
Xerox Europe

> -----Original Message-----
> From: Hall, Shaun [mailto:Shaun.Hall@gbr.xerox.com]
> Sent: 23 November 2000 12:04
> To: 'W3C WebDAV Mailing List'
> Subject: RFC2518 LOCK Response Code
> 
> 
> An issue regarding a LOCK response code in RFC2518. A quick 
> search in the
> archives didn't show anything about this.
> 
> In section 8.10.4, it states "If the lock cannot be granted to all
> resources, a 409 (Conflict) status code MUST be returned with 
> a response
> entity body containing a multi-status XML element...".
> 
> 1) The 409 status code is not listed in section 8.10.7 (LOCK 
> status codes).
> 2) The example in section 8.10.10 (Multi-resource LOCK 
> request which fails)
> returns a 207 (Multi-status) response code, not a 409.
> 
> The 207 response is normal for WebDAV methods that need to provide
> information about multiple-resources.
> 
> I'm inclined to think the 207 is the correct response in such 
> a failure
> case, which at first implies the 409 is wrong.
> 
> However, I think the only case where a 409 is applicable is 
> if one it trying
> to "create" a Lock Null Resource (LNR) (i.e. the 
> null-resource does not
> exist) and where the ancestors of the LNR do not exist. I 
> think this would
> be consistent with other methods as well (e.g. PUT, COPY, MOVE).
> 
> Comments/clarification/etc please.
> 
> Regards
> 
> Shaun Hall
> Xerox Europe
>

Received on Wednesday, 6 December 2000 12:21:38 UTC