[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: serf error handling for locks without authn

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Tue, 04 Jun 2013 00:47:01 +0100

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

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

This is an archived mail posted to the Subversion Dev mailing list.