Greg Stein <gstein_at_gmail.com> writes:
> On IRC, Ben and I tossed this around. The short answer is "the server
> is not configured to allow a LOCK operation." 501 (Not Implemented)
> states it is an appropriate status when the server is unable to
> support the request method.
> We can also adjust the error string in append_locks() to something like:
> "Anonymous lock creation is not allowed. The server configuration
> will not allow a LOCK."
> That points to the configuration problem. And the 501 is pretty darned
> close to what we want.
> As Ben noted on IRC, a 4xx response implies the client got something
> wrong. The root problem is on the server, and that implies a 5xx
501 was my first suggestion, it works quite well for the anonymous lock
attempt and the other cases where SVN_ERR_FS_NO_USER is currently
converted into 401. For a 501 the client gives
svn: warning: apr_err=SVN_ERR_RA_DAV_REQUEST_FAILED
svn: warning: W175002: LOCK request on '/obj/repo/A/f' failed: 501 Method Not Implemented
and the server logs "Anonymous lock creation is not allowed".
However there is another HTTP_UNAUTHORIZED: mod_dav_svn returns it from
/* Sanity check: does the incoming token actually represent the
current lock on the incoming resource? */
if ((! slock)
|| (strcmp(token->uuid_str, slock->token) != 0))
return dav_svn__new_error(resource->pool, HTTP_UNAUTHORIZED,
"Lock refresh request doesn't match existing "
I think this is a client sending the wrong lock token in an If: header,
so perhaps "412 Precondition Failed" is correct here?
Certified & Supported Apache Subversion Downloads:
Received on 2013-06-04 01:47:37 CEST