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

RE: Re: The Data Sanitization Plan

From: Bill Tutt <rassilon_at_lyra.org>
Date: 2002-06-25 22:55:23 CEST

> From: Greg Stein [mailto:gstein@lyra.org]
>
> > * 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
>
> I'm almost positive that you will have to type it that way.
>

Ick. No way. No typing in of URL escapes. That's EVIL to our users.
That's a big usability -1.

svn diff -r3:4 'http://path/to/my file' should be perfectly acceptable
command line input. That's clearly how a GUI is likely to get the data
when it is about ready to call the SVN APIs.

The really icky part I see here isn't the question mark related one.
What should the command line client do when it sees this command line:
        svn diff -r 3:4 http://path/to/my%20file

Should it escape the % or not? We don't want the URI accidentally double
escaped to something like: http://path/to/my%2520file

Of course, just to be annoying, there could theoretically be a file
called my%20file in the repository. What to do, what to do..

I'd tend towards this heuristic for deciding whether to escape the URI
for a command line client only:
* Escape all normally escaped characters except for the percentage sign.
(0x25)

This escapes most of the data when necessary and still allows a little
fudge room from pasting in URIs from browser address bars.

The only other alternative to that is a stat() like approach. i.e. see
if either non-escaped target, or the escaped target exist, and pick the
first one that exists as your winner.

Bill

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

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.