subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Reser <...@reser.org>
Subject Re: serf error handling for locks without authn
Date Tue, 04 Jun 2013 00:43:32 GMT
On Mon, Jun 3, 2013 at 5:24 PM, Konstantin Kolinko
<knst.kolinko@gmail.com> wrote:
> 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.

Yeah 405 is just as annoying for us to return because it's hard for us
to provide that list of allowed methods, since what really is allowed
can be configured by the user.

403 would be alright, but I'm inclined to think 501 is better in this
case since in practically all cases the server is misconfigured.
Outside of us developers nobody in practice runs a Subversion server
and allows anonymous commits.  We do it from time to time because
setting up authn/authz is annoying and we just want to test something
unrelated to that.

Mime
View raw message