* Roberto De Ioris <[email protected]> [2013-04-03 11:12]: >> Yes, that seems to be logical behavior. >> There's one additional, related issue, I would like to make these >> mountpoints conditional on a virtualhost/docroot, i.e. I have one >> uwsgi vassal per user which serves multiple sites but the >> mountpoint should only be valid for one of the virtual hosts. >> With some limitations I can already achieve that for WSGI through >> the new routing system but apparently not for CGI scripts, any >> ideas how that could be solved? Should I open an RFE on the >> bugtracker to discuss this? >> -- >> Guido Berhoerster > > > The current "approach" (instead of implementing virtualhosting in each > plugin) is exposing (where possibile) request plugins even to the routing > api. > > We already have static:, xslt:, gridfs:, ssi:... > > I think cgi: could be a great addition to versatility: > > route-if = equal:${HTTP_HOST};uwsgi.it goto:uwsgi.it > route-run = break: > > route-label = uwsgi.it > route-if = endswith:${PATH_INFO};.cgi cgi:/usr/lib/cgi-bin/${PATH_INFO} > > and so on
For WSGI apps I'm already (ab)using the new routing system for serving apps only for a certain virtualhost with a similar construction: plugins = 0:notfound,router_uwsgi,cgi,php,16:python [...] manage-script-name = true no-default-app = true mount = /some-app=/usr/share/some-app/some-app-wrapper.py route-host = ^(.+)$ goto:$1 route-label = foo.example.com route = .* goto:common-routing route-label = bar.example.com route-uri = ^/some-app/ uwsgi:,16,0 route = .* goto:common-routing route-label = common-routing [...] It's kind of a kludge since the two sites cannot serve different apps under the same path but other than that it's already working. Extending support for the routing system among request plugins, in particular the CGI one, would be really awesome. -- Guido Berhoerster _______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
