I'm trying to make svnserve imitate mod_dav_svn here, but having
problems.
In mod_dav_svn, we cache the svn_fs_t in a "global" pool, specifically
the connection's pool. As each http request comes in, we grab the
authenticated username attached to it, create a new svn_fs_access_t
object in r->pool, then attach the access_t to the svn_fs_t. We
register a cleanup handler on r->pool, so that when the request dies,
so does the access_t. This is the proper lifetime for authentication;
a request comes in with a username (and possibly lock-tokens), and the
authentication only lasts as long as the request itself.
We need svnserve to do the same thing. Luckily, it behaves much like
apache. There's a "global" pool (the one in the server_baton_t) which
holds the svn_fs_t, and when each new client command comes in, the
command is processed using a subpool.
At the moment, though, the lifetime of the access_t is inconsistent.
If the auth-challenge happens inside of a command handler, then
auth_request() is called using the command's subpool, and the access_t
is allocated in the subpool. When the subpool is cleared, the global
svn_fs_t points to a de-alloc'd svn_fs_access_t (ugh!). If the
auth-challenge happens up-front before any commands are executed, then
auth_request() is called using the global pool, and the access_t ends
up allocated in the global pool, persisting across multiple commands
(also bad.)
I'm not sure how to fix this. Any suggestions from those who know
svnserve better? Lundblad, ghudson, etc.?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 11 23:57:10 2005