I'm sorry that I did not test the patch properly on trunk.
I actually wasn't sure about adding regression tests, since the original
client has no support for the timeout feature and there is no common practice
of handmade HTTP requests in Python tests.
Thanks for fixing and committing this!
On Thu, Mar 20, 2014 at 3:04 PM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Sergey Raevskiy [mailto:sergey.raevskiy_at_visualsvn.com]
>> Sent: donderdag 20 maart 2014 09:47
>> To: Subversion Development
>> Subject: [PATCH] Fix lock timeout values handling in libsvn_ra_serf
>>
>> Hi!
>>
>> I've noticed, that Subversion 1.8.x client can't break lock if it has a
>> non-infinite timeout (for example, if lock was acquired by non-standard
>> WebDAV
>> client, like MS Office). The 'svn unlock' fails with following error:
>> [[[
>> svn: E170003: Server does not support locking features
>> svn: E125003: Bogus date
>> ]]]
>>
>> I've discovered, that this happens because lock timeout values is parsed
>> incorrectly in libsvn_ra_serf (while libsvn_ra_neon works correct).
>>
>> According to section 14.29 of RFC 4918 [1] the value of timeout XML
> element
>> is
>> transferred as TimeType (see section 10.7 of the same RFC). Instead of
>> handling
>> it properly, libsvn_ra_serf tries to parse it like X-SVN-Creation-Date
> header
>> (which uses ISO-8601 date format):
>
> Thanks...
>
> With a bit of python hacking I was able to reproduce this issue in our test
> suite.
>
> It looks like your fix was not tested on trunk, because it applies the fix
> to only one of the locations where we parse this value... And exactly the
> other one than that used by 'svn unlock'.
> (I think this code was shared between the two implementations on <= 1.8.x)
>
> In r1579588 I added the test and a slightly different patch.
> (The timeout value in the lock response is relative from the current time
> (=seconds remaining), not the time of the lock creation.)
>
> Bert
>
Received on 2014-03-21 15:22:37 CET