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

Re: meaningful error messages in http

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Tue, 7 Dec 2010 21:36:18 +0100

On Tue, Dec 7, 2010 at 9:18 PM, Nick Stokes
<randomaccessiterator_at_gmail.com> wrote:
>
>
> On Tue, Dec 7, 2010 at 1:11 PM, Andy Levy <andy.levy_at_gmail.com> wrote:
>>
>> On Tue, Dec 7, 2010 at 11:59, Nick Stokes
>> <randomaccessiterator_at_gmail.com> wrote:
>> > Hi all,
>> >
>> > I am serving our repositories over https, using Apache 2.2, via
>> > mod_dav_svn,
>> > also using mod_authz_svn for per directory access control.  Most users
>> > find
>> > the error messages cryptic (when there is a permission related error on
>> > checkout, commit, so on...)  and I am wondering if there is a way to
>> > customize these messages?
>> >
>> > For example, current (default?) set up spits out the following:
>> >
>> > If checkout fails due to insufficient permissions:
>> > svn: Server sent unexpected return value (403 Forbidden) in response to
>> > OPTIONS request for 'https://my.cool.server/foo/trunk'
>> >
>> > If checkout fails due to spelling error in repository name:
>> > svn: Server sent unexpected return value (403 Forbidden) in response to
>> > OPTIONS request for 'https://my.cool.server/f00/trunk'
>>
>> I don't think Subversion can tell the difference here. If my AuthZ
>> file specifies that I have access to /f00/trunk/ and I ask for
>> /foo/trunk/, all that's really known is that I asked for a path which
>> I do not have permission to access. Do you propose that the server
>> scan for all possible "similar" repositories/paths in an attempt to
>> find a match?
>>
>
> No. I did not propose that.  The question was simple: Is there way to
> customize error messages from httpd server (akin to customizing logs in
> apache as in http://tinyurl.com/svn-apache-logs)?  When users see "Server
> sent unexpected return value..." they assume there is something wrong with
> the server itself, despite the keyword "Forbidden" that follows. Besides,
> there is the redundant/misleading/irrelevant-for-client stuff there
> (OPTIONS, MKACTIVITY, respos ID).  e.g. svnserve error messages are much
> better.

Yes, I completely agree.

It's not about the server sending better messages, but about the
client (or client library or whatever) to transform that error message
into something meaningful for the user. The svn client knows what
operation the user is trying to execute, so it should be able to
formulate something sensible in the context of that operation.

Moreover, one would expect these kinds of error message to be exactly
the same regardless of the underlying protocol or server type (unless
it's some kind of protocol-specific error, like e.g. SSL handshake
failure or something (which should also be made into user-sensible
error messages, but might not be generic over all protocols)).

I don't know if there is already an issue for this in the issue
tracker, but regardless ... maybe we could have a useful discussion on
this mailinglist about what the error messages should say
specifically?

What would be most helpful for the user, in a concise and to-the-point
way, concrete enough yet not too extremely technical, maybe giving
some hints about what could be the cause, ... in all kinds of use
cases?

Cheers,

-- 
Johan
Received on 2010-12-07 21:37:19 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.