Re: serf error handling for locks without authn

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