subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <b...@qqmail.nl>
Subject RE: [PATCH] subversion issue #4174 - serf: checkout / export over https errors out with "svn: E730053: Error retrieving REPORT (730053)"
Date Mon, 20 Aug 2012 15:35:52 GMT


> -----Original Message-----
> From: lieven.govaerts@gmail.com [mailto:lieven.govaerts@gmail.com] On
> Behalf Of Lieven Govaerts
> Sent: maandag 20 augustus 2012 12:43
> To: Johan Corveleyn; Subversion Development; serf-dev@googlegroups.com
> Subject: Re: [PATCH] subversion issue #4174 - serf: checkout / export over
> https errors out with "svn: E730053: Error retrieving REPORT (730053)"
> 
> On Mon, Aug 20, 2012 at 10:18 AM, Johan Corveleyn <jcorvel@gmail.com>
> wrote:
> > On Sun, Aug 19, 2012 at 1:53 PM, Lieven Govaerts <svnlgo@mobsol.be>
> wrote:
> >> Hi Johan,
> >>
> >>
> >> as you seem to be the only one encountering issue 4174, would you mind
> >> testing attached serf patch?
> >> You'll have to update serf trunk to r1627 to apply it cleanly.
> >>
> >> It fixes the issue for me on Windows 7 with svn trunk and serf trunk.
> >> While I have tested the patches on Mac OS X too, I couldn't reproduce
> >> the original problem.
> >
> > Great, it works!
> >
> > - svn trunk@1374802 with serf trunk@1627 without patch: verified that
> > I could still reproduce the original issue.
> >
> > - svn trunk@1374802 with serf trunk@1627 with your patch: the issue
> > did not occur anymore. I could successfully export the dreaded large
> > working copy from our repository over https. I tried a couple of times
> > to be sure, and there was no problem anymore.
> >
> 
> Okay, thanks for testing! I've committed the fix in serf r1628.

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

> 
> regards,
> 
> Lieven


Mime
View raw message