On Tue, Feb 23, 2010 at 3:37 PM, C. Michael Pilato <cmpil...@collab.net> wrote: > Got the following bug report from one of our CollabNet Asia peers. I've not > attempted to reproduce the problem myself. This bug was experienced using > a 1.6.x client, but I don't know exactly which 'x'. Anybody else seen > similar?
Yeah, it's easy to reproduce with trunk. > > -------------------------------------------------------------------- > > serf looks having problem on handling double byte directory name. For > example, if you have the following structure in your repository: s/serf/ra_serf/ .. > > "svn list http://path_to_repo/日"; returns an error like: > svn: The PROPFIND response did not include the requested resourcetype value This is what happens: On the PROPFIND request "PROPFIND /svn/tst/!svn/rvr/285/trunk/%E6%97%A5 HTTP/1.1", the server responds with the propstat xml response. The interesting parts of that response are: .. <D:href>/svn/tst/!svn/rvr/285/trunk/%e6%97%a5/</D:href> .. <lp1:checked-in><D:href>/svn/tst/!svn/ver/285/trunk/%E6%97%A5</D:href></lp1:checked-in> .. <D:href>/svn/tst/!svn/rvr/285/trunk/%e6%97%a5/abcdefg</D:href> .. <lp1:checked-in><D:href>/svn/tst/!svn/ver/285/trunk/%E6%97%A5/abcdefg</D:href></lp1:checked-in> As you can see, the 日 character is encoded as either %E6%97%A5 (capital E) or %e6%97%a5 (lowercase e). This shouldn't be a problem, but ra_serf uses these paths as keys in a hash table to later retrieve them. It turns out they are first stored as /path/%E6%97%A5, and then later retrieved as /path/%e6%97%A5, which obviously doesn't work as paths are handled case sensitive. These paths are canonicalized before being used, but svn_uri_canonicalize doesn't touch the encoded characters. Maybe it should just convert those letters to lowercase? I don't really see a better fix. Lieven
