Re: meaningful error messages in http

On Wed, Dec 8, 2010 at 1:26 AM, Curley, John <John.Curley_at_windriver.com> wrote:
>
> -----Original Message-----
> From: Johan Corveleyn [mailto:jcorvel_at_gmail.com]
> Sent: Tuesday, December 07, 2010 12:36 PM
> To: Nick Stokes
> Cc: Andy Levy; users_at_subversion.apache.org
> Subject: Re: meaningful error messages in http
>
> On Tue, Dec 7, 2010 at 9:18 PM, Nick Stokes
> <randomaccessiterator_at_gmail.com> wrote:
>>
>>
> ... SNIP ...
>>
>> 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, repos 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 mailing list 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
>
>
> ----------------- My Response ------------------
>
> I partially agree with Johan and Nick.
>
> Being able to customize the messages would be good. 403 seems like a generic "did not work" code. However, I think in this case, one would need to add more Apache/SVN error codes. Having a (I am making this up) 403.1 - repository not found, 403.2 - authentication failed, et cetera, may be helpful.
>
> Where I disagree is in a secure environment. You probably do not want to acknowledge server names, or repository names if someone is  snooping around.
>
> Maybe that might be a difference between http: and https:. Just a thought.

No, that's not what I mean. Don't want to leak any more information
than necessary. The server's error messages are fine, it's just that
the client should translate that into user-language.

For example:

If checkout fails due to insufficient permissions:
Instead of:
    svn: Server sent unexpected return value (403 Forbidden) in
response to OPTIONS request for 'https://my.cool.server/foo/trunk'

it could be:
    svn: permission denied accessing 'https://my.cool.server/foo/trunk'

or:
    svn: checkout of 'https://my.cool.server/foo/trunk' failed because
of insufficient permissions.

or something with "authorization failed".

or ...

And that error message could be exactly the same whether you're using
Apache or svnserve (error has nothing to do with the protocol).

Most users don't know (or don't care) about HTTP error codes. And I
bet 99.9% of svn users don't know what an OPTIONS request is (and
they certainly don't care).

Cheers,

-- 
Johan