On Mon, Jun 3, 2013 at 6:09 PM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Greg Stein <gstein_at_gmail.com> writes:
>
>> On Mon, Jun 3, 2013 at 5:14 PM, Philip Martin
>> <philip.martin_at_wandisco.com> wrote:
>>> http://subversion.tigris.org/issues/show_bug.cgi?id=4368
>>>
>>> Locking with anonymous http fails because there is no username. At
>>
>> That should be allowed. A WebDAV lock does not require an owner.
>
> svn_fs_lock requires a username.
>
> * @a fs must have a username associated with it (see
> * #svn_fs_access_t), else return #SVN_ERR_FS_NO_USER. Set the
> * 'owner' field in the new lock to the fs username.
>
> What is mod_dav_svn going to do, invent a username?
Ah. Well... I would say "yes, invent a username". "_unknown_" or somesuch.
But that's just me :-)
I'm not sure if we can determine whether authn/authz is configured for
the particular path.
Oh. Wait. The config should prevent the LOCK even *before* it gets to
our code. IOW, if our code is reached *without* a username, then
authn/authz is not configured.
412 (Precondition Failed) is not appropriate, as there are no
preconditions defined in the headers (eg. an "If" header). The proper
response is 409 (Conflict). The client *may* be able to proactively
provide authentication information, but we can't use 401 to automate
the authn provision (for the lack of WWW-Authenticate, as you noted).
>>> present mod_dav_svn returns "401 Unathorized" however
>>
>> Do you know where/why this is happening?
>
> mod_dav_svn/locks.c:append_locks.
Yeah. HTTP_CONFLICT should be correct, there.
>...
And back to the client: yeah, determine_error() looks very wrong.
There should be some kind of fallback value for errcode.
Cheers,
-g
Received on 2013-06-04 00:31:46 CEST