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

Re: [PATCH] Remove redundant url-encoding added in r917523

From: Kamesh Jayachandran <kamesh_at_collab.net>
Date: Thu, 24 Mar 2011 19:41:39 +0530

On 03/24/2011 05:54 PM, vijay wrote:
> Just now I came to know that it fails in neon only.
>
> I configured neon as a default ra_layer in my runtime configuration area.
>
> When I use serf as ra_layer, the commit succeeds.

Yes that answers the failure I observed.

Please provide a testcase that exhibits the same failure for both neon
and serf.

Meanwhile analysing why it succeeds in serf would teach something
interesting.

With regards
Kamesh Jayachandran
>
> Thanks & Regards,
> vijayaguru
>
> On Thursday 24 March 2011 05:12 PM, Kamesh Jayachandran wrote:
>> Thanks for the Patch Vijay.
>>
>> In my FC14 your testcase passes both with and without patch.
>>
>> I am investigating....
>>
>> Will get back.
>>
>> With regards
>> Kamesh Jayachandran
>> On 03/24/2011 04:11 PM, vijay wrote:
>>> Hi,
>>>
>>> This patch adds a testcase for the regression triggered by r917523
>>> and fixes it.
>>>
>>> The revision r917523 do some url-encodings to the paths and uris in
>>> subversion/mod_dav_svn/mirror.c.
>>>
>>> <snip>
>>> $svn log -r917523
>>> ------------------------------------------------------------------------
>>>
>>> r917523 | kameshj | 2010-03-01 19:18:01 +0530 (Mon, 01 Mar 2010) |
>>> 26 lines
>>>
>>> With the below apache configuration(See the <space> character "/svn
>>> 1/").
>>>
>>> <Location "/svn 1/">
>>> DAV svn
>>> SVNParentPath /repositories
>>> </Location>
>>> <Location "/svn 2/">
>>> DAV svn
>>> SVNParentPath /repositories-slave
>>> SVNMasterURI "http://localhost/svn 1"
>>> </Location>
>>>
>>> Write through proxy is *not* happening and commit happens *directly*
>>> inside the slave.
>>>
>>> * subversion/mod_dav_svn/mirror.c
>>> (proxy_request_fixup): URI encode the to be proxied file name.
>>> (dav_svn__proxy_request_fixup): r->unparsed_uri is in url encoded
>>> form while
>>> root_dir is not in encoded form. So use r->uri to compare with
>>> root_dir.
>>> (dav_svn__location_in_filter): URL Encode the 'find & replace'
>>> urls as
>>> the request body has it in url encoded format.
>>> (dav_svn__location_header_filter): Encode the master_uri as the
>>> response from
>>> master has the Location header url encoded already. Set the
>>> outgoing Location
>>> header url encoded.
>>> (dav_svn__location_body_filter): URL Encode the 'find & replace'
>>> urls as
>>> the response body has it in url encoded format.
>>>
>>> ------------------------------------------------------------------------
>>>
>>> </snip>
>>>
>>> There is one extra url encoding in
>>> mirror.c:dav_svn__location_header_filter() which encodes the
>>> Location header response from master second time, which in turn
>>> causes failure while committing a path to slave repo which has space
>>> in it. The space in the path is encoded as "%20" first time, again
>>> it is encoded as "%2520", which fails with error "File not found"
>>> while committing.
>>>
>>> I have added a testcase for this issue in
>>> subversion/tests/cmdline/dav-mirror-autocheck.sh. I have just used
>>> the existing master and slave repo setup for my new test case.
>>>
>>> I have a plan of introducing "davmirrorautocheck" which we can
>>> execute like "make davmirrorautocheck", it will run all our python
>>> test suites via write-through proxy. All commits to the slave will
>>> be proxied to the master repo. The master repo's post commit hook
>>> will sync every commit to the slave repo. We can check whether slave
>>> and master repo are in sync in 'run_and_verify_commit'.
>>> We can extensively test our write-through proxy by making use of all
>>> our existing tests.
>>>
>>> Attaching the patch and log message.
>>>
>>> Thanks & Regards,
>>> Vijayaguru
>>>
>>>
>>>
>>>
>>>
>>
>
Received on 2011-03-24 15:10:03 CET

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

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