W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 2000

RE: RFC2518 LOCK Response Code

From: Clemm, Geoff <gclemm@rational.com>
Date: Wed, 6 Dec 2000 12:21:00 -0500
Message-ID: <3906C56A7BD1F54593344C05BD1374B10D9FC5@SUS-MA1IT01>
To: "'W3C WebDAV Mailing List'" <w3c-dist-auth@w3.org>
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


-----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?


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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:22 UTC