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

Re: [PATCH] subversion issue #4174 - serf: checkout / export over https errors out with "svn: E730053: Error retrieving REPORT (730053)"

From: Lieven Govaerts <svnlgo_at_mobsol.be>
Date: Mon, 20 Aug 2012 21:19:45 +0200

On Mon, Aug 20, 2012 at 5:35 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
> Maybe you should call SSL_get_error() in the handler to find out the exact
> reason on why OpenSSL reports the connection as closed?
> From man SSL_read on my FreeBSD box:
> 0 The read operation was not successful. The reason may either be a
> clean shutdown due to a "close notify" alert sent by the peer (in
> which case the SSL_RECEIVED_SHUTDOWN flag in the ssl shutdown
> state
> is set (see SSL_shutdown(3), SSL_set_shutdown(3)). It is also
> possible, that the peer simply shut down the underlying transport
> and the shutdown is incomplete. Call SSL_get_error() with the
> return value ret to find out, whether an error occurred or the
> connection was shut down cleanly (SSL_ERROR_ZERO_RETURN).
> SSLv2 (deprecated) does not support a shutdown alert protocol, so
> it can only be detected, whether the underlying connection was
> closed. It cannot be checked, whether the closure was initiated
> by
> the peer or by something else.
> Looking further through that man page I think serf should also handle
> SSL_ERROR_WANT_WRITE like SSL_ERROR_WANT_READ in the error handling block,
> but that is unrelated to this patch.
> Bert

I agree, there is some room for improvement here to handle all return
cases of the SSL API. I'm wondering if there's an easy way to simulate
all theses possible return paths, I don't like to add untested code.

Received on 2012-08-20 21:20:39 CEST

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