> Am 19.07.2018 um 17:29 schrieb Philip Martin <phi...@codematters.co.uk>: > > "Felix E." <felixes...@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
signature.asc
Description: Message signed with OpenPGP
