TurboGears apps with multiple web paths
Christoph Zwerschke
e.g. www.company.com, the easiest methods are using named virtual hosts
like appname.company.com or using URLs like www.company.com/appname/.
The former looks nicer, but the simple named virtual hosts are not
possible with SSL.
So ideally, I'd like to allow both kinds of URLs for my applications at
the same time. But the problem is that you can set only one root path in
TG using server.webpath. If you set it to "/", then the URLs
www.company.com/appname/ will not run correctly. If you set it to
"/appname", then the URLs appname.company.com will get /appname/
appended, which looks ugly and defeats the purpose of having named
virtual hosts.
One solution would be to run every application twice on different ports,
one instance with server.webpath="/" and another instance with
server.webpath="/appname", and let Apache proxy to the respective ports.
Not a really nice solution.
Another solution would be to have TG support per-host server.webpaths,
depending on the scheme and hostname that is used in the URL. This could
be implemented by allowing server.webpath to be a full URL including
scheme and hostname, e.g. "https://www.company.com/appname", and the
prefix "/appname" would be only used as webpath when the request is
using "https://www.company.com". We could also allow it to be a list
with several such URLs. It would require only some small changes in
turbogears.startup and turbogears.controllers. Anybody besides me who
thinks this is a good idea?
Or are there better solutions?
-- Christoph
Lukasz Szybalski
Is there a reason you are not using mod_wsgi deployment to achieve above ?
Lucas
Christopher Arndt
> On Wed, Jul 30, 2008 at 9:03 AM, Christoph Zwerschke <ci...@online.de> wrote:
>> So ideally, I'd like to allow both kinds of URLs for my applications at
>> the same time. But the problem is that you can set only one root path in
>> TG using server.webpath.
>
That's beside the question. Or can you show a way to solve the original
problem (running the application under two different webpaths) with
mod_wsgi?
Chris
Jorge Godoy
I can see some places where I could use that. If tied together with master
templates per "root" in an easier way than today's callable solution this
could really be interesting for code reuse.
> Or are there better solutions?
I don't know. I didn't stop to think about this yet because so far all
servers that I have installed applications are dedicated servers and only
serve one domain.
--
Jorge Godoy <jgo...@gmail.com>
Graham Dumpleton
TG is a good WSGI citizen, then it should honour the SCRIPT_NAME
variable passed in by a WSGI adapater as being the mount point of the
application. That is, SCRIPT_NAME should be used in preference to
server.webpath, especially if server.webpath is not defined.
If TG honours this, then using mod_wsgi one could do the following:
# Create WSGIDaemonProcess outside of VirtualHost so can be
# delegated to by mulitple virtual hosts.
WSGIDaemonProcess appname
# Allow access to WSGI script file for application.
<Directory /usr/local/turbogears/mysite/apache>
# Delegate this TG application to 'appname' daemon process and
# specifically the main interpreter in that process. Need to specify
# application group else different mount points across virtual hosts
# would result in there being multiple instances in process. Forcing
# it to main interpreter means there will be only one instance of
# application regardless of where it is mounted.
WSGIProcessGroup appname
WSGIApplicationGroup %{GLOBAL}
Order deny,allow
Allow from all
</Directory>
# Virtual host for appname.company.com.
<VirtualHost *:80>
ServerName appname.company.com
WSGIProcessGroup appname
WSGIApplicationGroup %{GLOBAL}
WSGIScriptAlias / /usr/local/turbogears/mysite/apache/
turbogears.wsgi
</VirtualHost>
# Virtual host for main company site.
<VirtualHost *:80>
ServerName www.company.com
WSGIScriptAlias /appname /usr/local/turbogears/mysite/apache/
turbogears.wsgi
</VirtualHost>
In other words, create a single daemon process and delegate the TG
application to run in main interpreter in that process via directives
in Directory container where TG WSGI script file is saved.
Different virtual hosts can then mount the WSGI script file at
different mount points and all requests will go to single TG app in
the single daemon process.
As mentioned above, this depends on SCRIPT_NAME being honoured for the
mount point. Any URL construction should also honour that and the
server name, protocol etc as described in WSGI PEP at:
http://www.python.org/dev/peps/pep-0333/#url-reconstruction
The question therefore is whether TG has been updated to be a well
behaved WSGI application yet as doing what is required is certainly
straight forward using mod_wsgi if it were. Based on documentation in:
http://code.google.com/p/modwsgi/wiki/IntegrationWithTurboGears
for TG 1.X it doesn't however honour SCRIPT_NAME, but has TG 2.0 fixed
this so it is?
Graham
Christoph Zwerschke
> The issue is whether TG is a true WSGI friendly application or not. If
> TG is a good WSGI citizen, then it should honour the SCRIPT_NAME
> variable passed in by a WSGI adapater as being the mount point of the
> application. That is, SCRIPT_NAME should be used in preference to
> server.webpath, especially if server.webpath is not defined.
Godd point. Instead of server.webpath, TurboGears should regard
SCRIPT_NAME which at least 1.0 does not do. If I understand correctly,
the place where this must be fixed is the controllers.url function,
something like:
tgpath = config.get('server.webpath',
cherrypy.request.wsgi_environ.get('SCRIPT_NAME', '')) + tgpath
Maybe we should fix this even in 1.0?
-- Christoph
Christoph Zwerschke
As Graham already commented, mod_wsgi does in fact not help since TG
does not heed SCRIPT_NAME.
However, if you use mod_proxy, then there is no way to get hold of the
original URL, so having different prefixes will not be possible on
principle (at least if you run only one instance of the application).
This was probably was Lukasz meant. (Correct me if I'm wrong.)
-- Christoph
Christoph Zwerschke
http://trac.turbogears.org/ticket/1919
Using this patch and mod_wsgi, you can now have both schemes
www.company.com/appname/ and appname.company.com for your application,
without setting server.webpath at all. Works nicely.
Let me know your opinion. Should we apply the patch? Or only in 1.5? Any
improvements?
-- Christoph