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

Re: [PATCH] Fix for Issue # 1267

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2003-07-20 15:18:17 CEST

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

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

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

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