On 23.08.2013 01:04, Philip Martin wrote:
> Branko Čibej <br...@wandisco.com> writes:
>
>> On 22.08.2013 22:40, Branko Čibej wrote:
>>> On 22.08.2013 18:11, kmra...@rockwellcollins.com wrote:
>>>> Passing an invalid URL to svn co causes an abort and core dump. This
>>>> fails with all protocols
>>>> http, svn, file. It occurs with all versions I tested (1.7.5, 1.7.11,
>>>> 1.7.12, 1.8.1, and the now defunct 1.8.2)
>>>> It occurs with multiple subcommand (ls, info, etc.) It happens on
>>>> both unix and windows platforms.
>>>> The "abort" is especially bad on Windows since it will pop open a
>>>> dialog window due to the abort.
>>>>
>>>> It is expected that the command line would return an appropriate user
>>>> friendly error message
>>>> instead of crashing when faced with invalid input.
>>>>
>>>>
>>>> ./svn co file://./test <file://test>
>>>> svn: subversion/libsvn_subr/dirent_uri.c:1315: svn_uri_basename:
>>>> Assertion `svn_uri_is_canonical(uri, ((void *)0))' failed.
>>>> Abort (core dumped)
>>> Interesting ... the assertion itself is fine, however, the command-line
>>> client should either reject invalid URL parameters, or canonicalize the
>>> input. Apparently we missed one.
>> Apparently all commands that accept an URL will abort in this way,
>> except for "svn relocate". So it looks like some kind of "policy" but I
>> think it's the wrong one.
> svn_uri_canonicalize allows any characters in hostname, A-Z is converted
> to a-z, other characters are simply copied:
>
> /* Found a hostname, convert to lowercase and copy to dst. */
> if (*src == '[')
> {
> ...
> }
> else
> while (*src && (*src != '/') && (*src != ':'))
> *(dst++) = canonicalize_to_lower((*src++));
>
> What is the canonical form of this?
>
> scheme://./
>
> Should we drop '.' to give:
>
> scheme:///
>
> or do we have to retain it as
>
> scheme://./
>
> and change svn_uri_is_canonical to allow a hostname '.'?
I believe this is relevant:
http://tools.ietf.org/html/rfc3986#section-3.2.2
A dot is neither an "IP literal encapsulated within square brackets,"
nor "an IPv4 address in dotted-decimal form." However, it may be a
"registerd name" under the rules described in that section. In other
words, Subversion could interpret it as an alias for localhost -- in
which case the only sane course of action IMO would be to canonicalize
file://./ to file:///.
On the other hand I'm not sure we're not allowed to do that for http://
and svn:// URLs.
-- Brane
--
Branko Čibej | Director of Subversion
WANdisco // Non-Stop Data
e. br...@wandisco.com
