[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: Bert Huijben <bert_at_qqmail.nl>
Date: Mon, 20 Aug 2012 17:35:52 +0200

> -----Original Message-----
> From: lieven.govaerts_at_gmail.com [mailto:lieven.govaerts_at_gmail.com] On
> Behalf Of Lieven Govaerts
> Sent: maandag 20 augustus 2012 12:43
> To: Johan Corveleyn; Subversion Development; serf-dev_at_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_at_gmail.com>
> wrote:
> > On Sun, Aug 19, 2012 at 1:53 PM, Lieven Govaerts <svnlgo_at_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_at_1374802 with serf trunk_at_1627 without patch: verified that
> > I could still reproduce the original issue.
> >
> > - svn trunk_at_1374802 with serf trunk_at_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
Received on 2012-08-20 17:36:30 CEST

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.