Re: PROPPATCH

On Mon, Sep 10, 2001 at 04:19:30PM -0500, cmpilato@collab.net wrote:
> Hey, Greg. I'm looking at the whole "we need to xml-escape our log
> messages" thing. As you've seen already, we are now xml-escaping
> those messages, but upon retrieval one can quickly see that nothing is
> "un-escaping" them on the server side.

You can't know that unless you see what is on the wire. If the content is
escaped twice before transmission, then the server does one unescape, then
you could arrive at the "no unescaping" conclusion.

But checking the wire is important.

-------------- woah woah...

Ah... I know what the problem is. It is related to the propdb API. mod_dav
escapes the property values before passing them to the backend. Thus, we
have two things to do:

1) when mod_dav_svn receives the property, it should unescape the XML

2) when mod_dav_svn supplies a property back to mod_dav, it should escape it

Once the mod_dav API is fixed, we will only need to do (2) (effectively, the
backend places the content on the wire, so it must be escaped).

So... short term, we do the above.

>...
> I saw in dav_svn_db_store() that this seems to handle both txn and
> node props, so my thinking was, "Well, I better not xml-unescape
> anything I don't know is xml-escape, and I don't know that node props
> are xml-escaped."

All props are escaped, per above.

>...
> Then I saw this:
>
> /* ### temp hack to remap the name. fix the value (skip lang; toss null). */
> fix_name(db, &propname);
> ++propval.data;
> propval.len -= 2;
>
> Oh, yeah, I remember that -- "the hack". But what I'm not sure about
> is the manipulation you're doing on PROPVAL, dropping the first and
> last characters, right?

The value from mod_dav is:

    LANG '\0' VALUE '\0'

LANG is always the empty string (it holds any extent xml:lang value; our
client never sends it, so we can assume it to be empty here). The above code
drops that leading NUL, and drops the trailing NUL.

> Either way, is there a simply way to un-escape the XML here, or do I
> have to set up an XML parser to do the job?

We have no structured properties, so a simple unescape will suffice (I don't
recall a function to do this, since Expat does it for us). When the API is
revamped, we won't be doing the unescape, so no problem.

In dav_svn_db_fetch(), where it assembles the resulting value in db->work,
you will need to XML escape the value. Use svn_xml since it works with a
stringbuf (Apache has an xml escaping function, but it doesn't use
stringbufs, so it isn't as "nice" for this particular situation).

Cheers,
-g

p.s. and yah... we'll have some back-patching to do on our log messages :-)

-- 
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