Greg Stein <[email protected]> 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
> response.
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
lock.c:refresh_locks:
/* 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,
DAV_ERR_LOCK_SAVE_LOCK,
"Lock refresh request doesn't match existing "
"lock.");
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:
http://www.wandisco.com/subversion/download
