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
-~----------~----~----~----~------~----~------~--~---

Reply via email to