Julian Foad wrote:
> Bert Huijben wrote:
>>> -----Original Message-----
>>> From: Ivan Zhakov [mailto:ivan_at_visualsvn.com]
>>> Using full URLs like protocol://server/repo/path instead of session
>>> relative path will be ideal solution. Another way is support both full
>>> URLs and repository relative paths.
>> One of the nice things of using just relative paths and not full urls
>> is that we can leave all encoding issues (especially over http/https)
>> to the ra layer implementations.
>>
>> It is very hard to escape special characters everywhere, and that is
>> precisely what most of our current full uri apis require. Everywhere
>> where we forget the escaping, we have a potential security issue.
>>
>> The new libsvn_wc code will not handle full uris internally. Only a
>> repository root and paths relative from this root.
>>
>> Everywhere we need a full url, we can perform a single
>> svn_path_url_add_component2() to handle the escaping of the relative
>> path in one place. Forcing escaped uris through all of the code is not
>> something I would like. (I fixed at least 5 or 6 issues caused by
>> wrong escaping in the 1.5.X branch; and there are more open reports of
>> similar issues that haven't been researched yet)
>
> +1 to what Bert says.
>
> I think we should in most cases be using a repository or session
> "object" that knows its root URL.
I think the problem that Ivan identified is a real one. His complaint isn't
so much that we have to do path-math, but that any time we need to access a
path that is in the same repository but not equal to or a child of the
session URL, we have to perform a silly workaround dance:
old_url = svn_ra_session_url()
svn_ra_reparent(new_url)
svn_ra_dosomething("")
svn_ra_reparent(old_url)
As a result of this annoyance, devs sometimes figure they'll avoid this
altogether by opening the RA session at the common parent of old_url and
new_url (in this example). But as we've seeing in issue #3242 and others,
that can cause unnecessary authz problems.
Perhaps the change we should make is that svn_ra_open() never, ever contact
the repository. It would return a session that is internally marked as
unverified and incompled. Then the first real operation on the RA session
-- including perhaps an explicit svn_ra_handshake() function -- would
contact the repository, do feature negotiation, etc. All the
repos-contacting stuff that ra_open() does today. This would allow us to
open an RA session to the root of the repository even if the user doesn't
have authz access there, and still use relative paths (to locations they
*do* have access to) for the real work without all the reparenting.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2407173
Received on 2009-10-13 22:57:53 CEST