Shlomi Fish <shlomif@vipe.technion.ac.il> writes:
> Resolves Issue #1267 (Have to say "No" several times to reject SSL
> certificate.)
>
> * session.c
> (server_ssl_callback): modified this function to set the ssl_certificate
> flags in the session baton.
>
> * ra_dav.h
> Added the ssl_certificate flags to the svn_ra_session_t baton.
>
> * util.c
> (svn_ra_dav__parsed_request): reset the ssl_certificate flags at the
> beginning of the request. Check for an SSL rejection and if so,
> return an authorization error.
OK, I've finally studied this patch, and now it's *my* turn to object
to it. (Poor Shlomi... :-) )
This patch adds a global cache to the RA session object, so that
svn_ra_dav__parsed_request can return SVN_ERR_RA_NOT_AUTHORIZED. This
causes svn_ra_dav__search_for_starting_props to stop retrying PROPFIND
requests on parent directories, because, at the moment, it's only
ignoring the more generic SVN_ERR_RA_DAV_REQUEST_FAILED.
But I don't like the RA-session cache at all; it seems to me like
somehow, we're failing to use neon properly (or neon has a bug?).
Notice that svn_ra_dav__parsed_request calls
svn_ra_dav__convert_error, which tries to map neon return-values to
svn error codes. In particular, a NE_AUTH failure code gets mapped to
SVN_ERR_RA_NOT_AUTHORIZED. But this mapping isn't happening, because
for some reason, neon is returning a generic error (NE_ERROR).
So my question is: why is this happening? It seems to me that if our
ssl callback returns failure to neon, neon should return NE_AUTH
failure, not NE_ERROR. If this were happening,
search_for_starting_props would be bailing out properly, rather than
retrying.
Joe Orton, any thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 20 15:20:45 2003