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

Enforce canonical paths in client-server protocol? [was: svn commit: r12738 - in trunk/subversion: include libsvn_subr mod_dav_svn]

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2005-01-16 17:10:42 CET

Greg Hudson wrote:
> On Sat, 2005-01-15 at 14:32, Julian Foad wrote:
>
>>>>An advantage of being strict is that it leaves room for us to extend the syntax
>>>>in future by assigning meanings to paths that are currently non-canonical. For
>>>>example, we might one day want to assign a meaning to the double-slash, as in
>>>>current discussions about svn:external. If we allow that now as being just a
>>>>sloppy equivalent of a single slash, then we shut that door.
>>>
>>>This doesn't work, since the command line client canonicalizes its
>>>arguments.
>>
>>This does work, since the client software that would talk this extended
>>protocol would not be today's client. I'm talking about future extensions to
>>the client-server protocol which would involve modifying both the client and
>>the server.
>
> I guess it depends on whether we're more worried about changing the
> protocol to break a non-conformant client, or changing the whole system
> to break a script or other tool which passes non-canonicalized paths to
> the command-line client.

Sorry, I don't understand that sentence at all; for as start, what does "it"
refer to?

The main thrust of this thread was discussing whether to require that paths
received by the server are canonical. Enforcing this would break
non-conforming clients, and it's not clear whether that would be good or bad in
the long run. In any case, I wouldn't describe that as "changing" the
protocol, just enforcing the current definition, but that depends on whether
you regard the specification or the implementation as definitive.

Then you talk about changing the whole system and breaking things. If you are
referring to my suggestion of extending the client-server protocol in future,
then you misunderstood: I was suggesting the possibility of extending it in a
backward-compatible way, such that all today's usage would remain the same but
additional features would be available (with some new command-line syntax or
other user interface to invoke them).

Whether a tool passes non-canonicalized paths to the command-line client need
not affect whether the client passes non-canonicalized paths to the server:
that's under our control.

- Julian

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jan 16 17:11:56 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.