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

[Andrew Bennetts]

Martin (gzlist) wrote:
> On 14/12/2007, Andrew Bennetts <andrew at canonical.com> wrote:
> > Andrew Bennetts wrote:
> > [...]
> > >
> > > I have code locally that works for bzr+http, even with a shared repository.
> >
> > And here it is.
> 
> I have tried this with the bzr-http-client branch merged too, and it
> works here as well. (with caveat about socket buffering on large
> packs)

Great!  Thank you very much for testing this.

[...]
> 
> I don't see why all the path-wrangling stages can't go in the
> RelpathSetter app, as that's what the name implies it should be doing.
> But as you've largely depreciated it, why not move the last bit of it
> into SmartWSGIApp and junk it?

Yeah, something needs to happen to RelpathSetter.  Perhaps it needs to adopt all
the path mangling (and possibly be renamed PathMangler?), or it should vanish
entirely.  I'm not sure which is better at this point, but it's definitely
something I'd like to sort out in a later patch.  For this patch I didn't want
to spend too long refactoring the universe to make things perfect, it was large
enough (and useful enough!) already that I decided to propose it as is.

> Oh, and a minor request, can we have:
> - def make_app(root, prefix, path_var, readonly=True):
> + def make_app(root, prefix, path_var="REQUEST_URI", readonly=True):
> I see no reason not to default it to the common value.

Yeah, I guess that's a good idea.  I originally decided against this because I
wasn't sure what a common value would be :)

But this seems fine to me now.

> > This, combined with the small change to fix the client-side path calculations
> > I've posted separately, makes bzr+http actually work in non-trivial situations.
> 
> That patch is also fine, though it can lead to a couple of  weird (but
> harmless) things, like requesting something that ends up as
> chroot://../... followed by chroot://../../... and thus making the
> server check the same thing multiple times.

Yeah.  In the long run this will be solved by replacing the VFS smart
calls with a smarter calls, so that lots of small file-oriented requests become
a few direct requests on a branch or repository object.  There's a long way to
go, though.

> I have an update-to-update of http_smart_server.txt in progress. Have
> successfully tested apache configuration and scripting that works for
> mod_python, mod_wsgi, mod_cgi (for fun, with some slight issues),
> mod_fastcgi (with some larger issues). Will attack the text before
> posting diff.

Great!  I'm looking forward to seeing it.

-Andrew.