The Data Sanitization Plan

Karl and I are talking about how to tackle issues #494 and #667
together as a unit. After reading and discussing, here's our Plan.

Essentially, we are imposing an Official set of burdens upon all svn
client applications, (i.e. any users of the libsvn_* libraries):

  1. all paths passed to libsvn_* are assumed to be

          - using '/' separators
          - using canonicalized case
          - in UTF-8
          
  2. all URLs passed to libsvn_* are assumed to be

          - properly URL-escaped
          - in UTF-8

  3. all log messages passed to libsvn_* are assumed to be
 
          - in UTF-8

Our thoughts are to create three utility routines in libsvn_subr,
something like:

    svn_sanitize_path()
    svn_sanitize_url()
    svn_sanitize_logmsg()

These utility routines would perform all the necessary transforms on
the data, according to the requirements above.

After that, it's a simple matter of making all of our cmdline client
code use these routines before passing data to libsvn_*.

==> How to implement the sanitization routines

  * Karl says apr_file_path_merge() will give us the "canonical" case
    of path components. That sounds good. Except the name of that
    func is really weird. :-)

  * Rumors has it that there exist various apr iconv routines to
    convert data to UTF-8. We've already decided that each
    sanitization func is going to take a locale argument; in the case
    of our cmdline client, this information can be gathered either by
    getting the system locale, or by using a particular locale from
    the commandline (--locale ?)

  * We can easily write a routine to convert '\' into '/'

  * The only real question is whether (and how) our cmdline client
    should "automatically escape" URLs. Is this too dangerous? Is
    there some reasonable heuristic to use? It would stink if I had
    to type this:

        svn diff -r3:4 http://path/to/my%20file

Feedback welcome...

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jun 25 21:54:21 2002