[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

write-through-proxy and checksum error - URL path mangled in text data

From: Sebastian Brandt <sbrandt_at_gmx.de>
Date: Tue, 19 Jul 2011 10:58:49 +0200

Dear folks,
Over the years, I have been getting weird "checksum error"s when committing
changes in certain files.

These ones are NOT related to the common problems of checksum errors with
svn, such as corrupted .svn/entries or .svn/text based, or windows xp sp1.

Master on W/xxx
Slave and Write-Through-proxy on V/xxx
Both are running debian 1.5.1dfsg1-

I always use V/xxx.

The "expected" checksum in the error cases was the checksum of the file I
was trying to commit; while the "actual" was always identical for the same
changes, but never the "expected" one.
A checkout of the project, and adding the change there always had the same
result. It happened with Windows/Tortoise (1.5), Windows/sliksvn (1.5) and
Linux/svn 1.6.

I finally found out that the problem was related to the write-through-proxy.
Using this as key words, I found the following discussions in dev@ and user@

"bug: mirror WebDAV munging checkins containing "/SVN" "

"write through proxy configuration on windows / apache / svn causing
checksum mismatch errors"

It seems that the write-through-proxy code checks the http post to adjust
URLs that are different between the proxy and the master.
Unfortunately, this is done
* for the whole http message
* case-insensitively

Thus, in any file containing "/XXX/" (in my sample), the XXX is converted
into xxx; the checksum on the main server then, correctly, fails.
Unfortunately, the XXX in our case is the code for the client we are
developing for; and thus, it is also used in, e.g., web service URLs ...
until I found out that svn mangles exactly these three letters.

Quotes from the links above:
Shane Beasley:
 It seems to be doing a case-insensitive search-and-replace from
 "remotepath" -- the path component of the master server URI ("/svn" in
 our case) -- to "localpath" -- apparently the root of the repository as
 the mirror knows it (also "/svn" in our case). I suspect that it's doing
 this search-and-replace against the file we're committing, in which case
 presumably it shouldn't be doing that -- although I'm not sure what it's
 supposed to be doing instead.

David Glasser:
  This does look pretty nasty. Like, "don't use this feature, it will
  corrupt your data" nasty.
  That filter is under-documented; I'm not sure what it's trying to
  convert. I suppose URLs in the metadata of requests. Justin, this is
  your code, right?

That discussion was two years ago; yet, I have been unable to find a
bug/issue report of this problem, or a documented fix.
So, before I post the bug report, I ask for feedback here - was the problem
observed by others, has it already been fixed in some 1.6.x version, etc.

Otherwise, I'll post this as an issue.

Received on 2011-07-19 12:20:13 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.