[MERGE][1.0][Bug 124089] Add root_client_path parameter to SmartWSGIApp, and use it to translate paths received from clients to local paths.

Martin (gzlist) gzlist at googlemail.com
Thu Dec 13 22:51:45 GMT 2007


Hm... a couple of confusing errors in my previous mail. Also, sorry Mr
B. Buggy, that was an informative patch against the branch, not a
suggested merge for trunk.

On 12/12/2007, Martin <gzlist at googlemail.com> wrote:
> > So what about defaulting to None, and using a DeprecationWarning if it
> > is not supplied.
>
> But this might be a good idea if over smart-server uses don't chroot.

s/over/other/

> For the abs path, the current code does the equiv. of
> path.join(chroot, "bzr.dev/", "./" +
> "/bazaar/bzr.dev/".split("/bazaar/",0)[1]) - which ends up duplicating
> the "bzr.dev" step.

That should be .split("/bazaar/",1)[1] - stripping the "/bazaar/" off
the front, at any rate.

A better general overview though is probably my bug comment
<https://bugs.launchpad.net/bzr/+bug/119330/comments/8> from some
months back. That suggested two solutions, John later expressed
preference for the second
<https://bugs.launchpad.net/bzr/+bug/119330/comments/9> and the
current branch uses the first.

On 12/12/2007, Andrew Bennetts <andrew at canonical.com> wrote:
> > > ...
> > > Also, as you mentioned, the documentation http_smart_server.txt needs to
> > > be updated.
> >
> > I could cover this... where's the current copy under
> > <http://doc.bazaar-vcs.org/bzr.dev/> though?
>
> It's at
> <http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#serving-bazaar-with-fastcgi>.

Ah, it's all mushed into one document now? Perhaps it doesn't want
expanding to include mod_wsgi then, don't want the docs too massive.

> I have code locally that works for bzr+http, even with a shared repository.
> I'll be posting it to the list later today.  It involves some small tweaks on
> the original patch I posted to this thread, some new logic in SmartWSGIApp (to
> adjust the root_client_path using the path from URL, so that paths inside the
> smart request can be adjusted correctly), and also some fixes to the paths sent
> by the RemoteHTTPTransport in some cases.  And test suite changes from the
> fallout of all that.

Cool. Is there any reason not to reuse the prefix to strip with the
RelpathSetter for the root_client_path though? Seems to be equivalent,
under the current design.

Martin



More information about the bazaar mailing list