[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: DAV locking question

From: Greg Stein <gstein_at_lyra.org>
Date: 2005-01-12 20:01:56 CET

On Wed, Jan 12, 2005 at 12:28:26PM -0600, Ben Collins-Sussman wrote:
>...
> UUID Token: opaquelocktoken:e7b934b9-7eed-0310-a22f-e4167952b748
> Owner: sussman
> Comment: <ns0:owner xmlns:ns0="DAV:">newlock</ns0:owner>
> Created: 2005-01-12 12:10:59 -0600 (Wed, 12 Jan 2005)
> Expires: never
>...
> But sure enough, I see this comment in the definition of the dav_lock
> struct:
>
> const char *owner; /* (XML) owner of the lock */
>
> Whassup with that? Is there a reason that the owner field is being
> stored with XML stuff around it? That's a bit of RA-specific "bleed"
> that we shouldn't be storing in the repository.
>
> Is my provider supposed to strip that XML stuff away? And if so, how?
> Am I allowed to make any assumptions about what sort of XML is there
> (i.e. is it safe to unconditionally strip away the outermost tag?)

RFC 2518, section 12.10 states that the DAV:owner element can contain any
XML child elements. IOW, it is structured data rather than a simple string
(see the example in section 8.10.8). Therefore, mod_dav serializes that
into a string and stores it into the ->owner field.

You could make some assumptions and try to lift some of the CDATA out of
there. I don't see explicit text in RFC 2518 that you MUST maintain that
element unchanged, but I would certainly assume it.

If the lock comes from an SVN client, then the assumptions will hold.
You'll be able to strip/rebuild the owner field.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jan 12 20:03:17 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.