On Thu, Feb 25, 2010 at 8:01 AM, Dariush Pietrzak
<ml-tortoise_at_kuszelas.eu> wrote:
>> > 192.168.223.129 - - [22/Feb/2010:09:20:31 +0100] "PROPFIND /svn/ProjectName/branches HTTP/1.1" 401 394 "-" "SVN/1.6.9 (r901367)/TortoiseSVN-1.6.7.18415 neon/0.29.3"
>> > 192.168.223.129 - username_at_KERBEROSDOMAIN.PL [22/Feb/2010:09:59:15 +0100] "PROPFIND /svn/ProjectName/!svn/bln/10514 HTTP/1.1" 207 268 "-" "SVN/1.6.6 (r40053)/TortoiseSVN-1.6.6.17493 neon/0.28.6"
>
>> Looks like a regression between Neon 0.28.6 and 0.29.3
> a bit, but I found that some users are using neon 0.29.3 with multiple different
> svn clients ( commandline for example ):
> 192.168.223.128 - login_at_KERBEROSDOMAIN.PL [22/Feb/2010:13:00:17 +0100] "PROPFIND /svn/Datacenter HTTP/1.1" 207 341 "-" "SVN/1.6.9 (r901367) neon/0.29.3"
> ..
> 192.168.23.128 - login_at_KERBEROSDOMAIN.PL [23/Feb/2010:13:38:28 +0100] "OPTIONS /svn/Datacenter HTTP/1.1" 200 149 "-" "SVN/1.6.9 (r901367) neon/0.29.3"
> and this: "SVN/1.6.6 (r40053) neon/0.29.3"
>
> and they do not report any problems. But those clients do show a bit strange
> behaviour - they constatly switch between authenticated and unauthenticated
> requests, while TortoiseSVN 1.6.6 for example stays authenticated all the
> time.
I verified the "odd" behavior with TortoiseSVN 1.6.7 (neon 0.29.3).
The first OPTIONS request sends the negotiate authentication fine, but
the secondary (and subsequent) PROPFIND requests only allow basic
auth.
(If it matters, this is against a svn 1.6.5 server built with neon
0.28.6 and mod_auth_kerb 5.4)
TortoiseSVN 1.6.7 does work with NTLM does work against mod_auth_sspi
against a (windows) svn 1.6.5 server built with neon 0.28.6...
Kevin R.
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2452194
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-02-25 20:21:12 CET