On 14.05.2015 19:47, Johan Corveleyn wrote:
> On Wed, May 13, 2015 at 9:00 PM, Clay Porter <clay.porter_at_gmail.com> wrote:
>> Hello,
>>
>> Everything is working now (see inline below). I can't thank you enough
>> for your help with this.
>>
>> On Tue, May 12, 2015 at 5:21 PM, Andreas Stieger <andreas.stieger_at_gmx.de> wrote:
>>> Hello,
>>>
>>> On 12/05/15 18:27, Clay Porter wrote:
>>>> svn: E175002: GET request failed: 400 Bad request
>>>> There is no corresponding error in the Apache HTTP logs.
>>>>
>>>> svn: E200014: Checksum mismatch for <file>
>>>> expected: 4b4ef9e3432aa84aed190457b68c01ad
>>>> actual: 863b9f52f352a5cb20298ef0eecb9e97
>>>> In this case the server logs have this:
>>>> [Tue May 12 12:13:05 2015] [error] [client 153.65.184.225] Unable to
>>>> deliver content. [500, #0]
>>>> [Tue May 12 12:13:05 2015] [error] [client 153.65.184.225] Could not
>>>> write data to filter. [500, #175002]
>>> Does setting/changing SVNAllowBulkUpdates make any difference?
>>> https://subversion.apache.org/docs/release-notes/1.8.html#serf-skelta-default
>> Setting SVNAllowBulkUpdates to Prefer has fixed the problem for me.
>> I checked the behavior using SVN clients 1.5 through 1.8 on various
>> platforms and all worked.
> I'm glad you got it fixed. However, it's not normal that serf's skelta
> mode (the default for 1.8 clients, unless they get instructed by the
> server with "SVNAllowBulkUpdates Prefer") doesn't work. If you have
> the time it might be interesting to investigate this a little bit
> further.
>
> You should be able to reproduce the issue again, even when your server
> is configured with "SVNAllowBulkUpdates Prefer", by using a client
> with http-bulk-updates=no in its "servers" configuration file (see the
> release notes snippet that Andreas pointed to). This will instruct
> your client to never use bulk-updates mode (i.e. force skelta mode),
> even though the server prefers it.
>
> Some possible reasons for the error you were seeing include problems
> with proxies or firewalls between client and server. Or other
> components that interfere with the network communication, rewriting
> packets or things like that (e.g. antivirus components, surf shield
> stuff, ...). Skelta mode uses a lot more small requests/responses
> (instead of one huge "update response" for the bulk-updates mode), so
> maybe some security component on your network considers this an
> insecure pattern, and decides to drop things ...
We had a similar report a while ago ... which turned out to be a bug in
a Cisco ASA/IOS PIX, which had HTTP deep packet inspection enabled.
Turns out that once its internal queue of packets is full, it'll just
start dropping them. A browser user (almost) doesn't care, since she
just reloads the page and hopes for the best blaming "flaky internet
connection". The SVN client, on the other hand, isn't so forgiving. :)
-- Brane
Received on 2015-05-14 20:08:13 CEST