Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: domain of knst.kolinko@gmail.com
 designates 209.85.214.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CABD8fLV8EVSp=Fa2Zi900ye7WDP_bSQxPqpvKbxP017AqSKWEQ@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>
	<CABD8fLV8EVSp=Fa2Zi900ye7WDP_bSQxPqpvKbxP017AqSKWEQ@mail.gmail.com>
Date: Tue, 4 Jun 2013 04:24:29 +0400
Message-ID: 
 <CABzHfVmKAzSwSWR+8TJQpQL0=QhQaFQSkY76MwZNP2-mDUdgig@mail.gmail.com>
Subject: Re: serf error handling for locks without authn
From: Konstantin Kolinko <knst.kolinko@gmail.com>
To: Greg Stein <gstein@gmail.com>
Cc: Ben Reser <ben@reser.org>, Philip Martin <philip.martin@wandisco.com>,
	Subversion Development <dev@subversion.apache.org>
Content-Type: text/plain; charset=ISO-8859-1

2013/6/4 Greg Stein <gstein@gmail.com>:
> 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.
>

If you are considering 501 then there also exists 405 Method Not Allowed
An implementation difference though is that 405 must be accompanied by
an Allow header.

Difference between 405 and 501 is also specified in ch.5.1.1 of RFC
2616 (HTTP/1.1),
Quoting from there:
[[[
   The list of methods allowed by a resource can be specified in an
   Allow header field (section 14.7). The return code of the response
   always notifies the client whether a method is currently allowed on a
   resource, since the set of allowed methods can change dynamically. An
   origin server SHOULD return the status code 405 (Method Not Allowed)
   if the method is known by the origin server but not allowed for the
   requested resource, and 501 (Not Implemented) if the method is
   unrecognized or not implemented by the origin server.
]]]

On a generic HTTP server if authentication is required but is not configured
I would consider returning 403.
I do not know whether that would work for Subversion in this case though.

Best regards,
Konstantin Kolinko