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

Re: locking: serious RA interoperability problems.

From: Daniel Patterson <danpat_at_danpat.net>
Date: 2005-02-14 20:37:53 CET

Ben Collins-Sussman wrote:
> 2. When a non-dav RA layer stores a lock structure in the repository,
> the lock->comment field has no XML wrapping. Later on, mod_dav
> reads the lock and sends it to some DAV client (svn or otherwise),
> but the HTTP response is invalid, because there's no XML wrapping
> around the field! mod_dav doesn't realize that it needs to add XML
> wrapping.

   I'm a little confused, but I don't see a great big problem here....

   If DAV locks always store lock-comment = "<D:author>blah blah
blah</D:author>", then surely it's safe for mod_dav_svn to strip
   "<D:author>", store only "blah blah blah", and re-wrap "<D:author>"

   That way, if a non-DAV client gets a lock, mod_dav_svn still serves
   back XML, even though the opaque data may not make sense to all
   DAV clients (but this is the case when using different DAV clients
   anyway isn't it? they don't all store the same data inside
D:author..). Sure, non-DAV clients might see pretty noisy lock
   comments, but I think that's the price of working with DAV clients
   at the same time. Either that, or as you suggested, create a new
   lock property like "lock-metadata" or something that a non-DAV
   ra layer doesn't use.

   If DAV locks do *not* always come from the DAV client wrapped by
"<D:author>", then it's also a non-issue. If DAV doesn't guarantee
   that the author field is wrapped by "<D:author>", then mod_dav_svn
   could just XML escape the lock-comment data (s/</&lt;/ for example)
   and serve it back as-is, +/- some smarts to not escape it if it's
   got D:author at the start.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Feb 14 20:40:40 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.