svn 1.2 and neon 0.25 -- xml-escaping problem.

This is a question about how to deal with a problem regarding upcoming
svn 1.2 and (pending?) neon 0.25.

After a bunch of experimental verification, here's what's going on
when ra_dav creates a lock:

1. user runs 'svn lock foo.c -m "<foo>"'.

    * ra_dav calls ne_lock(), but manually xml-escapes the lock comment
      before sending. (neon isn't doing it).

    * apache's front-end xml parser unescapes the request body

    * mod_dav xml-escapes the comment again

    * mod_dav_svn *possibly* unescapes the comment (depending on
      whether it was an svn client doing the lock or not), then stores
      in the repository.

2. svn client tries to fetch a lock

    * ra_dav calls ne_lock_discover(), which issues a PROPFIND

    * mod_dav_svn pulls the lock out of the repository, and possibly
      xml-escapes the comment (depending on whether an svn client
      originally created the lock).

    * mod_dav and apache don't touch the data at all

    * neon's xml parser xml-unescapes the comment and hands the
      original "<foo>" back to subversion.

So... why am I explaining all this? cmpilato and I are worried about
future headaches regarding neon 0.25.

In particular, we're worried that if neon 0.25 learns to automatically
xml-escape outbound lock comments, then this xml-escaping will be
happening twice: once by ra_dav, once by neon. Very bad.

In a perfect world, neon 0.25 would be pushed out ASAP with this fix
(as well as the control-c bugfix), and we'd require it for svn 1.2.
And then ra_dav wouldn't do any xml-escaping.

In a not-so-perfect world, we'd have to add runtime detection code for
pre-neon-0.25 libraries, and make ra_dav's xml-escaping conditional.
Ick.

What should we do?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 9 22:31:38 2005