Error "The server sent an improper HTTP response." on commit with Subversion 1.8+ client
Asked Answered
A

2

9

Recently I have been plagued by an error on committing to a single SVN repo using TortoiseSVN (1.8.7.25475) or AnkhSVN (2.5.12471.17):

Error running context: The server sent an improper HTTP response

Here is a screenshot of the error in TortoiseSVN:

TortoiseSVN 'Improper HTTP Response' Error

The pixels differ of course, but the error is the same in AnkhSVN.

This only seems to affect attempts to commit modifications, not additions or deletions; and I can commit mods to several other SVN repos on the same server just fine.

Since my teammates continue to commit mods to the repo in question and the issue has only struck my commits to that repo, I tried committing simple mods after a fresh checkout of the repo: a few one-mod-at-a-time commits worked, but then...same error.

I also searched for, reviewed, and tried some possible solutions (e.g. in a thread on the TortoiseSVN forums to which Stefan Küng replied) - a registry tweak (deleting HKEY_CURRENT_USER\Software\Tigris.org - after exporting it for backup of course), checking my global properties, and ensuring that I am not using a proxy. Same error.

Finally, I tried both repairing and downgrading TortoiseSVN. Same error.

Has anyone else encountered this error under similar circumstances and found a solution to it?

Note that some related search results mention tweaking httpd.conf or other aspects of the SVN server, but server tweaks seem inappropriate to me. Again, my teammates continue to commit mods to the same repo using the same version of TortoiseSVN, the same OS (Win 7 Pro 64-bit) etcetera. Maybe I have missed something on the server that could just happen to affect me, though.

Aerodontia answered 2/7, 2014 at 18:35 Comment(5)
What antivirus do you have installed? Do you get the same error is the antivirus is completely unintstalled? Is there any proxy/firewall between your machine and the server?Pisciculture
@bahrep: I would prefer not to say, but me and my teammates all use the same antivirus. Still, it is a reasonable question to ask, and I will look the role it may play. As far as any proxy/firewall between my machine and the SVN server, I do not believe there is; but I will double check. Still, me and my teammates would all be affected by this.Aerodontia
there are issue related to faulty Cisco / firewall / antivirus stuff, so it's helpful to know what you have in your environment at least.Pisciculture
@bahrep: Ah, gotcha. Thanks for the heads up. I will check the details of any network intermediaries and look into the AV possibility too.Aerodontia
Same problem here with Tortoise 1.9.4 but the suggested solution (setting http-bulk-updates = yes) did not work :(Rainy
P
11

Upgrade your Subversion client to the latest version.


Outdated answer:

ON THE CLIENT MACHINE! Open %APPDATA%\Subversion\servers in a text editor and add the line http-bulk-updates = yes, save the file and see if it helps.

If it helps, you'd better configure Apache HTTP Server's httpd.conf with SVNAllowBulkUpdates prefer directive so that all Subversion 1.8 clients could connect without any errors.

If there are more than just you who get this error in your organization and adjusting server's configuration is still unacceptable, you can change the setting http-bulk-updates = yes via Windows Registry so adjusting this on all affected machines can be done via AD Group Policy.

Read more info in Apache Subversion 1.8 Release Notes.

P.S.: faulty network hardware / firewall / antivirus is still the root cause here. The above is just a workaround to revert to the behavior of Subversion 1.7 and older client with neon network library. BTW, I guess that the installed antivirus is NOD32 or BitDefender.

Pisciculture answered 3/7, 2014 at 13:47 Comment(7)
This looks very promising, and I will give it a try later this morning. Thank you. If the issue proves to be RTFM-preventable (well RTFRL-preventable), it will certainly get me back in the habit of reading the release notes with every TSVN update. I've definitely avoided pain by reading them thoroughly in the past...but admittedly become a little complacent after several smooth, uneventful TSVN updates. :/Aerodontia
@Aerodontia that's not really a RTFM-issue I'd say. It's the unexpected behavior and the cause is VERY unclear for regular users.Pisciculture
That worked beautifully. Okay then, let me off the hook as I try to put the onus on me. ;} I think the root of the issue actually reads pretty clearly - just needed to find it in my case. Thanks for pointing me in the right direction!Aerodontia
That worked beautifully for my wired connection, but it turns out that the problem persists with my wireless connection, which I have learned does use an HTTP proxy. I am digging into the proxy's effect. Thanks for highlighting that possibility.Aerodontia
It helped me too - I did all of the above + updated my TortoiseSVN client + restarted my PC and it's all back to normal now.Annulus
@Annulus with up to date TortoitseSVN 1.9 client I guess it will work without these config adjustments.Pisciculture
Maybe you're right, I should've tried to update TortoiseSVN first before trying to modify anything else but the programmer in me prevailed :-)Annulus
C
2

In my case it was problem with nginx's gzip (I run SVNEdge SVN server behind Nginx).

I disabled gzip and everything started working.

Cohbert answered 1/6, 2015 at 9:44 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.