Comment 8 for bug 119330

Right, better write up my resolutions from the other day to the first issue, in case anyone wants to have a look at this at some point.

For simplicity, the walkover below is using the path names from the current http_smart_server.htm doc.

So, branch is intended to be:
bzr branch bzr+http://example.com/code/someproject

Where url requested works out as:
http://example.com/code/someproject/.bzr/smart
'--scheme+domain-''---givenpath---''--added--'
                  '-------actualpath---------'

The server location is
/srv/example.com/www/code
'---baselocation---''-----webvisible-----

Note that though the /code/... paths to access through the server corresponds to a ./code/... directory in the filesystem in this example, there's no actual need for there to be any *real* 'code' directory in the server's filesystem at all. It could be various different bazaar repos from different locations all exposed via aliases in the server configuration.

The script location (though again, this could really be anywhere) is given as:
/srv/example.com/scripts/bzr-smart.py

In the script, the config for smart_server_app sets:
    root='/srv/example.com/code', prefix='/code/'

This maps the path:
/srv/example.com/code
to:
chroot-xxxx:///
*and* establishes a prefix that the wsgi server will strip before dealing with request urls.

So, a real request will come in over HTTP in the form:
POST /code/someproject/.bzr/smart
With attached body with instructions for the smart server.
The wsgi script will strip off front "/code/" and rear "/.bzr/smart" to give "someproject" and add to chroot to give chroot-xxx:///someproject as relative link to be used later.
The problem comes from the strings that are posted (and passed straight through to the bzr server untouched by wsgi). When requests are given with relative paths:
'get\x01.bzr/branch-format'
Join chroot-xxx:///someproject and .bzr/branch-format to form chroot-xxx:///someproject/.bzr/branch-format which reduces to /srv/example.com/www/code/someproject/.bzr/branch-format - which is right.
However, requests are also made with absolute paths from the server url namespace:
'BzrDir.open\x01/code/someproject/'
Join chroot-xxx:///someproject and /code/someproject/ (abs. path clobbers existing part) to make chroot-xxx:///code/someproject/ which reduces to /srv/example.com/www/code/code/someproject/ - which is not right.

Note, you can 'fix' this particular example by rolling the root= of the smart_server_app up one level and having an empty prefix. This is only due to the coincidence of the absserverpath mapping directly to the filesystem (which is not guaranteed), and also gives the smart server a jail containing the whole webserver, rather than just the code dir. At any rate, the config as given in the example doc appears to just not to work.

I have a patch that actually fixes this behaviour, but by subclassing chroot and just changing the behaviour of abspath to kill the prefix. Which is cute, but obtuse and really not The Right Thing. Basically, either the smart server needs to understand that it might be passed absolute paths to some scheme it's not using, or the client needs to not issue requests that use absolute paths that may not map cleanly to the actual filesystem.
Anyway, when this and the other issue are resolved in trunk, I have a rewrite of http_smart_server doc to do to greatly simplify the mod_python instructions.