> Am 19.07.2018 um 17:29 schrieb Philip Martin <philip_at_codematters.co.uk>:
>
> "Felix E." <felixessig_at_gmail.com> writes:
>
>> I understand that the very first request shouldn't contain any auth header.
>> But If a svn function is called multiple times(for the same host etc.) and
>> there was already a successful authentication, it should be possible to add
>> the auth header to the following requests instead of waiting for a auth
>> required response. At least I hoped so.
>
> It's not just the auth header -- the repeat client calls create/destroy
> complete TCP connections, so for https:// that involves cert exchange
> and renegotiating the encryption keys. Ivan did some work on fixing
> this in the past by caching the connections, but that proves tricky
> because the client API allows the caller (you) to change the user
> credentials between calls and reusing the session with the wrong
> credentials is bad. It's hard to fix at the higher level RA layer
> because the RA layer doesn't know about the credentials.
>
> Without connection caching the obvious place to store the auth knowledge
> is missing. One way to fix this bit might be to have the lower ra_serf
> layer cache the credentials, perhaps in long lived pool provided by the
> caller or via a callback provided by the caller. The ra_serf layer
> knows all about username, auth method, auth token, repository root,
> etc. so it could decide when to reuse.
>
> --
> Philip
Ok thanks for your detailed answer.
I did some work with the serf client and cached the credentials there (
not as part of subversion).
That’s why I thought it may be possible to use the the right auth params or
config etc. to keep the credentials. I just thought there could be a way
to configure the svn client in a way that not every function call leads
to authentication required response from the server.
Felix
Received on 2018-07-19 18:19:09 CEST