Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of gstein@gmail.com designates
 209.85.212.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CABD8fLUGzK23eS-gi2XPtDhHTAw-YCVyKshHr-Z2XoZFgReamA@mail.gmail.com>
References: <87y5aqgam0.fsf@ntlworld.com>
	<CABD8fLVSox+GgGWaqBZjipqCrD8ZuJ3oC+ZUYDj59dWhaE1=dw@mail.gmail.com>
	<87txleg82u.fsf@ntlworld.com>
	<CABD8fLV7u9SsXam2s975WAmaSBAR_=K2oCz7AXXvJUAfm9RV4w@mail.gmail.com>
	<CADkdwvQFgmmucoVFd3KMekZQLbyYh+BV0-PKr2X45OM=TdNJrg@mail.gmail.com>
	<CABD8fLUGzK23eS-gi2XPtDhHTAw-YCVyKshHr-Z2XoZFgReamA@mail.gmail.com>
Date: Mon, 3 Jun 2013 19:23:54 -0400
Message-ID: 
 <CABD8fLV8EVSp=Fa2Zi900ye7WDP_bSQxPqpvKbxP017AqSKWEQ@mail.gmail.com>
Subject: Re: serf error handling for locks without authn
From: Greg Stein <gstein@gmail.com>
To: Ben Reser <ben@reser.org>
Cc: Philip Martin <philip.martin@wandisco.com>,
	Subversion Development <dev@subversion.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Jun 3, 2013 at 7:10 PM, Greg Stein <gstein@gmail.com> wrote:
> On Mon, Jun 3, 2013 at 6:48 PM, Ben Reser <ben@reser.org> wrote:
>...
>> I'd argue that we should return a 500 range error since the problem
>> here is that the server is not properly configured.  There is really
>
> Nah. 500 means there is nothing the client can do, which isn't quite
> accurate. A client *could* go ahead and fill in an Authorization:
> header. (tho I don't know if Apache will parse it, without a config
> there)
>
>> nothing a client can do to resolve the issue other than to
>> authenticate, which our client is only going to do if the server is
>> setup properly.  So I'd vote for returning HTTP_INTERNAL_SERVER_ERROR.

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.

Cheers,
-g