> -----Original Message-----
> From: Ivan Zhakov [mailto:ivan_at_visualsvn.com]
> Sent: dinsdag 13 oktober 2009 16:45
> To: C. Michael Pilato
> Cc: dev_at_subversion.tigris.org
> Subject: Re: [RFC] Concept of RA session relative paths
> On Tue, Oct 13, 2009 at 6:27 PM, C. Michael Pilato
> <cmpilato_at_collab.net> wrote:
> > Ivan Zhakov wrote:
> >> Hi,
> >> Could you please someone explain me what's the purpose of session
> >> relative path in Subversion RA API?
> > The history is deep here, but it probably boils down to the fact that
> > passing relative paths thru the RA API simplified interaction with
> > client and working copy logic which also tended to deal with relative
> > while crawling around, and with the editor API which accepts paths
> > to the root of the edit. Also, back in the day, the client/WC layers
> > know the repository root URL, so calculating a repository abspath
> would have
> > required round-tripping the server.
> Currently all RA providers reveals repository root on connect and
> store it session baton. So it's really cheap to get it for client/WC
> layers. Just to clarify: I suggest to keep opening RA session by any
> URL in repository, but switch other API.
> 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)
Received on 2009-10-13 22:41:18 CEST