Re: [neon] excessive data transfer with SSPI

Joe Orton wrote:
> Hi Stefan,
>
> On Wed, Jan 11, 2006 at 08:16:52PM +0100, Stefan Küng wrote:
>> With my latest patch to the SSPI feature in neon, the authentication now
>> works, whether the user is part of a domain or not.
>> But there's one more problem we (TSVN users) discovered with it:
>> adding or checking out big compressed files leads to excessive data
>> transfers. Some examples:
>>
>> 14.585MB wmv file added with SSPI authentication ==> data transferred:
>> 278.362MB!
>>
>> The same file added (and committed) with basic authentication only
>> transferred 12.88MB data!
>
> Can you capture neon debug logs or ethereal traces and make them
> available to me? (preferably with a small file being committed to
> illustrate the problem)

I first have to rebuild everything again with those debug logs enabled.
But not today anymore, it's getting late here...

> If the server requires authentication only for PUT requests, then it
> might be expected that some of the request bodies have to be resent
> after authentication, when checking in. I can't think why checking
> *out* would lead to problems of the same magnitude, though.
>
> Trying to do GSSAPI-style authentication over HTTP is really inherently
> flawed since GSSAPI provides connection authentication whereas HTTP
> authentication is per-request. Some implementations of the server side
> (mod_auth_sspi in this case) will require the client to reauthenticate
> at every request, for this reason. Enabling KeepAlive in the httpd
> configuration may work around that.

I don't think the KeepAlive is disabled. At least the connection is
persistent and not closed every time. That's what puzzles me: even
though the connection stays open, Subversion/neon still re-authenticates
for every packet sent.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org