I've placed this issue up at critical, because fox2mike discovered it while we were working on the svn.overlays migration onto the new server. When we do the switchover, it's going to break everybody that is using serf instead of neon. How to reproduce: 1. Set up Apache with SVN 2. Put squid in front of Apache 3. USE="webdav-serf -webdav-neon" emerge subversion 4. # svn co http://overlaystest.gentoo.org/svn/proj/php/ Actual results: svn: XML parsing failed: (411 Length Required) Doing a tcpdump on during the co request, and comparing the requests, the Neon version sends PROPFIND with Content-Length, while serf sends PROPFIND without Content-Length, which thus upsets squid.
(In reply to comment #0) > 3. USE="webdav-serf -webdav-neon" emerge subversion FYI, if you have Subversion installed with USE="webdav-neon webdav-serf", then you can enforce the use of Serf by setting the 'http-library' option in ~/.subversion/servers: [global] http-library = serf
http://code.google.com/p/serf/issues/detail?id=28 http://groups.google.com/group/serf-dev/browse_thread/thread/d0f05ab5038b7e98 http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=144099 http://svn.haxx.se/dev/archive-2008-10/0523.shtml
I'd vote for masking the webdav-serf USE flag for now as the serf support causes currently way too much problems.
(In reply to comment #3) > I'd vote for masking the webdav-serf USE flag for now -1 for masking this flag. An elog notice in the ebuild will be sufficient.
> An elog notice in the ebuild will be sufficient. > I've came to an issue with subversion + USE="webdav-serf" while simply checking out Django svn co http://code.djangoproject.com/svn/django/trunk Moreover svn co https://<same addr> segfaults.
*** Bug 250447 has been marked as a duplicate of this bug. ***
Any updates on this recently?
(In reply to comment #5) > > An elog notice in the ebuild will be sufficient. > > > I've came to an issue with subversion + USE="webdav-serf" while simply checking > out Django > svn co http://code.djangoproject.com/svn/django/trunk > > Moreover svn co https://<same addr> segfaults. > Same here. Problem still exists.
same problem here, subversion is quite unusable on this machine getting a lot of svn: OPTIONS of 'http://svn.repository.site': could not connect to server (http://svn.repository.site) please help !!!
kunitoki: just rebuild with USE=-webdav-serf P.S. If you ask a question, add yourself to the CC list!
ok now is going better (using only neon), but i'm still having issues with using >=neon-0.28.4: that neon version should be had masked at least ! Look here: http://bugs.gentoo.org/show_bug.cgi?id=264101 Ok i finally got subversion working again. I please the great gentoo developers to check at least some critical apps (like subversion is for other DEVELOPERS) before committing stable keywords to them.
Is this bug still valid?
(In reply to comment #12) > Is this bug still valid? Upstream bug [1] is still open. [1] http://code.google.com/p/serf/issues/detail?id=28
It doesn't look like upstream is going to fix this soon. Can we at least add in a notification about the issue through elog/ewarn?
Comment #5 in Serf issue #28 suggests that Subversion now (since 2012) contains a workaround for this bug in Serf. Could somebody test if this problem still occurs with newest Subversion?
It seems that the fix is only in Subversion 1.8.*.
any news? upstream is now at serf-1.3.9
