TG2 on Webfaction - Make TG not see the extra part of the URL

4 views
Skip to first unread message

El Tea

unread,
Jul 19, 2009, 5:54:52 PM7/19/09
to TurboGears
I installed a version of TG2 on Webfaction. I can have a number of
installations there, and can have URLs redirected to each
application. So I can have something like this:

http://mysite.webfactional.com/
http://mysite.webfactional.com/sitea/
http://mysite.webfactional.com/siteb/

Each of those URLs will go to a different install of TG2. However,
unless I install TG2 at the root URL, it doesn't behave correctly -
the CSS doesn't load for example. I feel like I should be able to do
one of the following:

a) Configure my webfaction account so it "hides" the /sitea or /siteb
from the URL when requests are passed to TG2.
b) Configure TG2 so it expects that its root URL comes with a /sitea
and automatically adds it where required.

Any guidance on how to approach this would be appreciated.

Damjan

unread,
Jul 19, 2009, 8:47:00 PM7/19/09
to TurboGears
> I installed a version of TG2 on Webfaction.  I can have a number of
> installations there, and can have URLs redirected to each
> application.  So I can have something like this:
>
> http://mysite.webfactional.com/http://mysite.webfactional.com/sitea/http://mysite.webfactional.com/siteb/
>
> Each of those URLs will go to a different install of TG2.  However,
> unless I install TG2 at the root URL, it doesn't behave correctly -
> the CSS doesn't load for example.  I feel like I should be able to do
> one of the following:
>
> a) Configure my webfaction account so it "hides" the /sitea or /siteb
> from the URL when requests are passed to TG2.
> b) Configure TG2 so it expects that its root URL comes with a /sitea
> and automatically adds it where required.
>
> Any guidance on how to approach this would be appreciated.

Are you proxy-ing?
You probably need a SCRIPT_NAME fix WSGI middleware like this :

def proxy_fix(app, prefix=''):
def wsgi_app(env, start_response):
env['SCRIPT_NAME'] = prefix + env.get('SCRIPT_NAME', '')
return app(env, start_response)
return wsgi_app

El Tea

unread,
Jul 20, 2009, 12:45:55 AM7/20/09
to TurboGears
Thanks for the help. I eventually figured out how to use subdomains
properly and the issue went away, but I really appreciate your
thoughts on this one. It showed me an interesting part of TG that I
have not yet been exposed to.


On Jul 19, 8:47 pm, Damjan <gdam...@gmail.com> wrote:
> > I installed a version of TG2 on Webfaction.  I can have a number of
> > installations there, and can have URLs redirected to each
> > application.  So I can have something like this:
>
> >http://mysite.webfactional.com/http://mysite.webfactional.com/sitea/h...

Christoph Zwerschke

unread,
Jul 20, 2009, 3:29:03 AM7/20/09
to turbo...@googlegroups.com
Damjan schrieb:

> Are you proxy-ing?
> You probably need a SCRIPT_NAME fix WSGI middleware like this :

This already exists as part of paste.deply; you only need to add it to
your config file:

http://pythonpaste.org/deploy/class-paste.deploy.config.PrefixMiddleware.html

(Btw, in TG1 it was only one config setting, server.webpath).

If you're using mod_wsgi instead of mod_proxy, then I think you can do
this with the WSGIScriptAlias directive.

-- Christoph

Christoph Zwerschke

unread,
Jul 20, 2009, 3:34:30 AM7/20/09
to turbo...@googlegroups.com
El Tea schrieb:

> Thanks for the help. I eventually figured out how to use subdomains
> properly and the issue went away, but I really appreciate your
> thoughts on this one.

But the issue will come again when you want to use SSL for your subapps,
since virtual hosts won't work in this case unless you equip all of them
them with their own IP address and certificate.

I recently had the same issue and wondered why it was so badly
documetned since it's a frequent need.

-- Christoph

Graham Dumpleton

unread,
Jul 20, 2009, 8:17:17 AM7/20/09
to TurboGears


On Jul 20, 5:29 pm, Christoph Zwerschke <c...@online.de> wrote:
> Damjan schrieb:
>
> > Are you proxy-ing?
> > You probably need a SCRIPT_NAME fix WSGI middleware like this :
>
> This already exists as part of paste.deply; you only need to add it to
> your config file:
>
> http://pythonpaste.org/deploy/class-paste.deploy.config.PrefixMiddlew...
>
> (Btw, in TG1 it was only one config setting, server.webpath).
>
> If you're using mod_wsgi instead of mod_proxy, then I think you can do
> this with the WSGIScriptAlias directive.

For mod_wsgi things should just work properly to begin with, there
should be no need to fiddle with SCRIPT_NAME and PATH_INFO provided
that TG2 is doing the correct thing and honouring SCRIPT_NAME as the
mount point. The TG2 application also has to ensure that it uses the
correct functions for constructing absolute URLs for the same
application when doing redirects etc.

The only time where one may need to do a fixup when using mod_wsgi is
where using AddHandler and trying to get a .wsgi file to appear as
being at root of web site. In this case you need a Apache rewrite rule
and a WSGI wrapper to truncate SCRIPT_NAME appropriately. This is
described in mod_wsgi configuration guidelines documentation.

The problem with using mod_proxy is that you loose information between
the front end and back end where mount point in each is different.
That is, where front end mounts at sub URL but front end is all setup
to mount at root. The back end should really be mounting at sub URL as
well in that case, but often this isn't done.

Graham

Damjan

unread,
Jul 20, 2009, 3:41:49 PM7/20/09
to TurboGears

> > Are you proxy-ing?
> > You probably need a SCRIPT_NAME fix WSGI middleware like this :
>
> This already exists as part of paste.deply; you only need to add it to
> your config file:
>
> http://pythonpaste.org/deploy/class-paste.deploy.config.PrefixMiddlew...

There's also wsgiproxy which I think is more up to date version of the
same..
http://pythonpaste.org/wsgiproxy/class-wsgiproxy.middleware.WSGIProxyMiddleware.html

anyway, that PasteDeploy middleware does some funky things with the
PATH_INFO which are not neccessearylu needed in all proxy
configurations. Which is why I wrote the simplest fixer above, so that
the OP could see what it's actually doing.

The PasteDeploy middleware has good points about mapping some of the
other variables, though. I use something similar, but I also check if
the request is coming from a proxy and only then "fix" the environ.
Reply all
Reply to author
Forward
0 new messages