Hi,
we recently upgraded our servers to Apache 2.2.25 and Subversion 1.7.11.
Since then several of our users have problems commiting files with blanks
somewhere in the pathname.
Symptoms are always the same:
Apache error_log shows
[Tue Aug 27 16:54:27 2013] [error] [client xx.xx.xx.xx] Unable to PUT new
contents for
/svn/repo/!svn/wrk/dcc67069-7dca-3141-8016-18787681c6d8/My%20Project/AssemblyInfo.vb.
[403, #0]
[Tue Aug 27 16:54:27 2013] [error] [client xx.xx.xx.xx] Could not create
file within the repository. [404, #160013]
[Tue Aug 27 16:54:27 2013] [error] [client xx.xx.xx.xx] File not found:
transaction '5252-4fa', path '/My%20Project/AssemblyInfo.vb' [404, #160013]
and the relevant lines from the Apache access_log
xx.xx.xx.xx server jdoe [27/Aug/2013:16:54:26 +0200] "MKACTIVITY
/svn/repo/!svn/act/dcc67069-7dca-3141-8016-18787681c6d8 HTTP/1.1" 201 241
"-" "SVN/1.6.16 (SharpSvn/1.6.16) WIN32/6.1 SharpSvn/1.6016.1637.10768
VisualStudio/9.0.21022.8 AnkhSVN/2.1.10129.17 neon/0.29.5"
...
xx.xx.xx.xx server jdoe [27/Aug/2013:16:54:27 +0200] "CHECKOUT
/svn/repo/!svn/ver/5090/My%20Project/AssemblyInfo.vb HTTP/1.1" 201 375 "-"
"SVN/1.6.16 (SharpSvn/1.6.16) WIN32/6.1 SharpSvn/1.6016.1637.10768
VisualStudio/9.0.21022.8 AnkhSVN/2.1.10129.17 neon/0.29.5"
xx.xx.xx.xx server jdoe [27/Aug/2013:16:54:27 +0200] "PUT
/svn/repo/!svn/wrk/dcc67069-7dca-3141-8016-18787681c6d8/My%2520Project/AssemblyInfo.vb
HTTP/1.1" 404 363 "-" "SVN/1.6.16 (SharpSvn/1.6.16) WIN32/6.1
SharpSvn/1.6016.1637.10768 VisualStudio/9.0.21022.8 AnkhSVN/2.1.10129.17
neon/0.29.5"
Note that the URL in the PUT request looks like it has been URL-encoded
twice
("...%20..." in the CHECKOUT URL got turned into "...%2520...").
The actual Subversion client varies (TortoiseSVN, SharpSVN, SVNKit etc),
but it must be using
the pre-HTTPv2 protocol, e.g. SVN 1.6.x.
I downgraded the server to Apache 2.2.24 and the problem went away.
I traced the actual TCP conversation in one of this cases and the double
URL encoding seen
is caused by the server: it sends the double encoded URL in the Location
header of its
response to the CHECKOUT request.
Cheers, Roderich
