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

Re: Interesting problem with ":" in mod_dav_svn XML output

From: Michael Sinz <Michael.Sinz_at_sinz.org>
Date: 2005-10-27 04:14:12 CEST

Kalle Olavi Niemitalo wrote:
> Michael Sinz <Michael.Sinz@sinz.org> writes:
>>Kalle Olavi Niemitalo wrote:
>>>I think this is a bug. If Subversion does not allow slashes in
>>>file names, it should say so in the error message, rather than
>>>treat %2F as a directory separator.
>>That is the problem - how would such a file ever be handled at the FS layer or
>>the URI layer - the escaping/unescaping happens before the path is taken apart.
> Well, if the interface of the URI unescaping code makes it
> impossible to preserve the distinction between "%2F" and "/",
> then I think the unescaper should allow just one of them,
> presumably "/", and return an error if it sees the other.

First, who should return the error? Who should parse the URL/URI and
pick/choose as to what is an error and what is not? The client side
really should not as it is perfectly legal to "escape" any character
that the client may have problems with.

The good thing is that very few filesystem implementations support the "/"
within a filename/dirname (at least at the interface layer)

> The same applies to "%00" versus end of string

Ahh, the horrible (but easy to use) C-string bites again :-) Really,
that is a language implementation detail which also exists in many APIs
to filesystems. Who should error that? And in what way?

Michael Sinz                     Technology and Engineering Director/Consultant
"Starting Startups"                                mailto:michael.sinz@sinz.org
My place on the web                            http://www.sinz.org/Michael.Sinz
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 27 04:15:24 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.