within php you can use
virtual("/some/url");
this seems to work without specially configured output filters in
apache,
I've also tried to add
AddOutputFilter INCLUDES .php
and within php have <!--#include virtual="/test.wsgi"--> and that for
some reason did not work.
On Aug 30, 5:25 pm, Evgeny <[email protected]> wrote:
> It works. Here is what I did for my minimal test.
>
> httpd.conf:
> <VirtualHost ...>
> ....
> DocumentRoot /path/to/dir
> AddHandler wsgi-script .wsgi
> AddType text/html .shtml
> AddOutputFilter INCLUDES .shtml
> ...
> </VirtualHost>
>
> <Directory /path/to/dir>
> Options ExecCGI Includes
> ... more stuff needed to run php application
> </Directory>
>
> test.shtml:
> <body>
> <!--#include virtual="/test.wsgi"-->
> </body>
>
> test.wsgi:
> def application(environ, start_response):
> status = '200 OK'
> response_headers = [('Content-type','text/plain')]
> start_response(status, response_headers)
> return ['Hello!']
>
> On Aug 30, 4:49 pm, Graham Dumpleton <[email protected]>
> wrote:
>
> > 2009/8/31 Evgeny <[email protected]>:
>
> > > Graham,
> > > sorry. That's exactly what I meant.
> > > I have a php application into which I want to inject bits generated by
> > > django,
> > > where django app runs under wsgi.
>
> > > Want those bits to be included via
> > > <!--#include virtual="/some/url" -->
> > > within the same VirtualHost.
>
> > > I'd write django to give output in form of html snippets rather than
> > > fully fledged pages.
>
> > > Will this work?
>
> > > (I've seen some conflicting posts on the subject, so decided to ask
> > > here)
>
> > Where are the conflicting posts about it. I can't see what the issue
> > is, so long as things are configured correctly in Apache to allow it.
>
> > What have you tried so far?
>
> > Graham
>
> > > Thanks.
>
> > > On Aug 29, 8:52 pm, Graham Dumpleton <[email protected]>
> > > wrote:
> > >> 2009/8/30 Evgeny <[email protected]>:
>
> > >> > I'm also curious about this - will Apache server side includes (SSI)
> > >> > work with the scheme offered below?
>
> > >> If you mean by way of:
>
> > >> <!--#include virtual="/some/url" -->
>
> > >> The SSI include is done by way of Apache sub request and so full URL
> > >> passing is still applied. Thus, is same as having triggered request
> > >> from outside of server.
>
> > >> If this doesn't answer question, not sure what you are asking and you
> > >> will need to explain further.
>
> > >> Graham
>
> > >> > Thanks!
>
> > >> > Evgeny.
>
> > >> > On Aug 10, 4:18 pm, Graham Dumpleton <[email protected]>
> > >> > wrote:
> > >> >> 2009/8/11 Haes <[email protected]>:
>
> > >> >> > Hi,
>
> > >> >> > I'm looking to integrate wsgi applications (Django in this case)
> > >> >> > into
> > >> >> > a legacy PHP web application. The legacy app is way to big to be
> > >> >> > completely rewritten all at once.
>
> > >> >> > Right now there are two wsgi apps installed in two subdirectories
> > >> >> > and
> > >> >> > more to come. The only way to configure apache was to set up a
> > >> >> > WSGIDaemonProcess for each of the two wsgi apps and point the
> > >> >> > WSGIScriptAlias to the respective subdirectory. That way I'll need
> > >> >> > at
> > >> >> > least two daemon processes (http and https) for every part I will
> > >> >> > exchange.
>
> > >> >> You don't need seperate daemon processes for HTTP and HTTPS, you can
> > >> >> share the same one. You can achieve this in two ways.
>
> > >> >> The first is to make the daemon process globally available by placing
> > >> >> WSGIDaemonProcess directive outside of the VirtualHost container and
> > >> >> then use WSGIProcessGroup to reference the same daemon process group.
>
> > >> >> Using this first approach means that daemon process is usable from any
> > >> >> VirtualHost, even ones not for the virtual host you need it for, if
> > >> >> hosting many virtual hosts.
>
> > >> >> The second and which constrains the use of the daemon process group to
> > >> >> virtual hosts with same ServerName, is to place WSGIDaemonProcess
> > >> >> directive in one (not all), of the virtual hosts for that ServerName.
> > >> >> That is, put in in VirtualHost for port 80. Then use WSGIProcessGroup
> > >> >> in VirtualHost for port 80 and 443 and refer to it.
>
> > >> >> This works because you can use WSGIProcessGroup to reference a daemon
> > >> >> process defined for same ServerName regardless of what port the
> > >> >> VirtualHost is for. Thus can reference across matching VirtualHost
> > >> >> containers.
>
> > >> >> I actually would have preferred that this only work that way for
> > >> >> 80/443, but not possible with the way that Apache works for me to
> > >> >> filter based on anything except ServerName value.
>
> > >> >> > Is there a way to only set up one set of WSGIDaemonProcess'es and
> > >> >> > just
> > >> >> > exclude certain path's from this configuration and let them being
> > >> >> > served by mod_php?
>
> > >> >> As gert said, first step is to use AddHandler to map .wsgi files to
> > >> >> mod_wsgi. You need to go further than that though as you don't want
> > >> >> lots of .wsgi files for each URL. You also don't want to have to add
> > >> >> lots of Alias directives for each PHP script. Instead you want to
> > >> >> route any URLs which don't map to static files or to PHP through to a
> > >> >> single WSGI application. To do that, would use:
>
> > >> >> Options ExecCGI
>
> > >> >> AddHandler wsgi-script .wsgi
>
> > >> >> RewriteEngine On
> > >> >> RewriteCond %{REQUEST_FILENAME} !-f
> > >> >> RewriteRule ^(.*)$ /site.wsgi/$1 [QSA,PT,L]
>
> > >> >> That is, add a site.wsgi which contains the code to map to your Django
> > >> >> application, with Django code being stored outside of HTTP document
> > >> >> tree somewhere. Whenever Apache can't find a physical resource file,
> > >> >> ie., static file or PHP script, it will send it to Django.
>
> > >> >> The only trick with this is that because of the rewrite, the
> > >> >> SCRIPT_NAME for Django willinclude'site.wsgi', which you don't want
> > >> >> because if you use Django to generate full URLs it willincludeit.
> > >> >> Thus you want to use a WSGI middleware wrapper to drop that from
> > >> >> SCRIPT_NAME.
>
> > >> >> import os, sys
> > >> >> sys.path.append('/usr/local/django')
> > >> >> os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings'
>
> > >> >> import django.core.handlers.wsgi
>
> > >> >> _application = django.core.handlers.wsgi.WSGIHandler()
>
> > >> >> import posixpath
>
> > >> >> def application(environ, start_response):
> > >> >> # Wrapper to set SCRIPT_NAME to actual mount point.
> > >> >> environ['SCRIPT_NAME'] = posixpath.dirname(environ['SCRIPT_NAME'])
> > >> >> if environ['SCRIPT_NAME'] == '/':
> > >> >> environ['SCRIPT_NAME'] = ''
> > >> >> return _application(environ, start_response)
>
> > >> >> Now, whether the root of the web site will be routed to Django
> > >> >> probably depends on whether you have a resource corresponding to
> > >> >> DirectoryIndex. Can't remember exactly how that works.
>
> > >> >> Anyway, this is all documented in:
>
> > >> >> http://code.google.com/p/modwsgi/wiki/ConfigurationGuidelines#The_Apa...
>
> > >> >> Have a read of that section, and the remainder of the document, have a
> > >> >> play and come back with any questions or clarifications.
>
> > >> >> Graham
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"modwsgi" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/modwsgi?hl=en
-~----------~----~----~----~------~----~------~--~---
