Justin Erenkrantz <justin@erenkrantz.com> writes:
> --On Monday, March 31, 2003 18:33:31 +0100 Philip Martin
> <philip@codematters.co.uk> wrote:
>
> > This has been suggested before, and last time I asked how it would
> > work at checkout. Doesn't auth occur before the UUID is available?
>
> As I said before, it depends on your authentication model and what
> your working copy state is. For initial anon-read/auth-write
> repositories, it should be possible to obtain the UUID before doing
> the commit. For auth-read/auth-write, you won't know initially what
> the UUID will be since you can't look at the repository until you are
> authorized. You'd just have to prompt in all cases.
Yuck, this is awful.
ra_local knows the UUID the instant you call RA->open() -- it creates
an fs object based on the file:/// url, and grabs the UUID from the
fs immediately.
ra_svn knows the UUID the instant you call RA->open() -- it opens a
socket to an svnserve process, and the initial handshake includes a
UUID exchange.
ra_dav, however, is really messed up in this department. RA->open()
doesn't immmediately connect to the network, and that's perfectly
fine. But the *only* way it can get a UUID is by doing a PROPFIND
right now, which might be an auth-protected request. This is absurd.
This is exactly why I said (a while back) that the repository UUID
should be a custom X-SVN header sent by the server. Any time httpd
sends a "401 Authorization Required" response, the UUID should be sent
in the response header. End of problem.
gstein, is there anything wrong with that solution? Otherwise it
seems like ra_dav is in a chicken-and-egg situation. And I don't want
to make libsvn_auth jump through absurd retry hoops to get around it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Apr 2 20:59:49 2003